[C++] Segmentation faults on Fedora 24 with pyarrow-manylinux1 and self-compiled turbodbc

[asfimport]

Original issue: blue-yonder/turbodbc#102

When using the pyarrow manylinux1 Wheels to build Turbodbc on Fedora 24, the turbodbc_arrow unittests segfault. The main environment attribute here is that the compiler version used for building Turbodbc is newer than the one used for Arrow.

Reporter: Uwe Korn / @xhochy
Assignee: Uwe Korn / @xhochy

PRs and other links:

• GitHub Pull Request #1464

_{Note: This issue was originally created as ARROW-1171. Please see the migration documentation for further details.}

[asfimport]

Wes McKinney / @wesm:
Seems like disabling the gcc5 ABI may be the solution?

[asfimport]

Uwe Korn / @xhochy:
No, we already disabled that. With enabled gcc5 ABI, it won't even link.

[asfimport]

Uwe Korn / @xhochy:
For reference, an import of this mixture (pyarrow-manylinux1 0.6.0 & turbodbc-self-compiled 2.2.0 on Fedora 24) fails with

Thread 1 (Thread 0x7f927a5db700 (LWP 21)):
#0  0x00007f9278df4110 in vtable for arrow::StringType () from /venv/lib/python2.7/site-packages/pyarrow/libarrow.so.0
#1  0x00007f92789d2069 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() () from /venv/lib/python2.7/site-packages/pyarrow/libarrow.so.0
#2  0x00007f92792cc948 in __run_exit_handlers (status=0, listp=0x7f92796505d8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#3  0x00007f92792cc995 in __GI_exit (status=<optimized out>) at exit.c:104
#4  0x00007f92792b3738 in __libc_start_main (main=0x563816bf87b0 <main>, argc=3, argv=0x7ffc0b05e9f8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7ffc0b05e9e8) at ../csu/libc-start.c:323
#5  0x0000563816bf87e9 in _start ()

[asfimport]

Wes McKinney / @wesm:
Is the self-compiling Fedora 24 user using devtoolset or stock gcc?

[asfimport]

Uwe Korn / @xhochy:
Stock GCC, so there is a version mismatch. I learned a bit more about -Bsymbolic and its friends, giving this a shot to see if that fixes it.

[asfimport]

Uwe Korn / @xhochy:
-DCMAKE_CXX_FLAGS='-Wl,-Bsymbolic -static-libstdc++' seems to solve the issue, marking this for the next release. I'll not do a direct PR but rather understand the effect a bit better.

[asfimport]

Uwe Korn / @xhochy:
Moved to 0.9.0 as the decimal code throws exceptions once I add -Bsymbolic to the linker options. This seems to take much longer to correctly understand the varying behaviour.

[asfimport]

Antoine Pitrou / @pitrou:
As a sidenote, a new manylinux standard is being developed with a more recent baseline (CentOS 6) :
https://www.python.org/dev/peps/pep-0571/

The PEP is still being discussed but chances are it will be accepted soon:
https://mail.python.org/pipermail/distutils-sig/2018-March/032102.html

Perhaps it will end the libstdc++ issues (or perhaps not :-)).

[asfimport]

Uwe Korn / @xhochy:
It will not end the issues but help us to move to a more modern compiler for the manylinux1 packages. We will still get issues when the wrong symbols are pulled in, probably for a lot less symbols than currently.

[asfimport]

Antoine Pitrou / @pitrou:
I'm assuming the issue is that the libstdc++ Arrow was (statically or not) linked with also gets used at runtime to resolve symbols in turbodbc (or the reverse)? Am I right?

Apparently another solution would be to use something called a "version script" to control which symbols are exported from the Arrow library, so that the static libstdc++ doesn't participate in dynamic symbol resolution:

https://www.technovelty.org/c/what-exactly-does-bsymblic-do.html

http://anadoxin.org/blog/control-over-symbol-exports-in-gcc.html

(I may be speaking cluelessly here)

[asfimport]

Uwe Korn / @xhochy:

I'm assuming the issue is that the libstdc++ Arrow was (statically or not) linked with also gets used at runtime to resolve symbols in turbodbc (or the reverse)? Am I right?

Yes. There are some symbols that are in the C++ STL that are always statically linked. We provide a version script and don't export our symbols but sadly other libraries export theirs and this then leads to a crash in Arrow.

Using -Bsymbolic (and friends!) would be the path that would ensure that Arrow actually uses the symbols that were packaged with it. Sadly this has some nasty side effects. When I have some more time, I try to dive into this issue again and read also the linked articles. Currently this problem here is no a high priority for me.

[asfimport]

Wes McKinney / @wesm:
Is this reproducible?

[asfimport]

Uwe Korn / @xhochy:
Yes, this is reproducible and probably not fixable.