nongnu-libunwind 1.2.1 can cause the C/C++ CloudI API to segfault under load about cloudi

[okeuday]

It is possible to avoid this segfault by using clang instead of gcc for the compilation. Using either libunwind (LLVM unwinder) or libgcc (GCC unwinder) as the clang -unwindlib value for link-time results in a compilation that doesn't have the http_req_c binary segfault when performing rapid C++ throw execution. The compilations used are shown below from usage on Ubuntu 20.04 LTS (with its packages):

-unwindlib=libunwind usage below:

export CXX='clang++-10'
export CC='clang-10'
export CXXFLAGS='-I/usr/include/c++/9 -I/usr/include/x86_64-linux-gnu/c++/9'
export LDFLAGS='-rtlib=compiler-rt -unwindlib=libunwind -L/usr/lib/gcc/x86_64-linux-gnu/9'
./configure
make
# ... install and other commands as done previously

-unwindlib=libgcc usage below:

export CXX='clang++-10'
export CC='clang-10'
export CXXFLAGS='-I/usr/include/c++/9 -I/usr/include/x86_64-linux-gnu/c++/9'
export LDFLAGS='-unwindlib=libgcc -L/usr/lib/gcc/x86_64-linux-gnu/9'
./configure
make
# ... install and other commands as done previously

The same nongnu-libunwind library (version 1.2.1) is linked in both compilations for C++ backtrace support, though the execution is able to avoid using nongnu-libunwind for exception handling, which avoids the segfault under load.

The segfault also didn't occur when using a build with gcc on Ubuntu 22.04 LTS in a VirtualBox VM which is using nongnu-libunwind library (version 1.3.2).

[ojura]

Hi, I am the bug submitter.

Note that compilers (e.g. gcc) provide their own internal unwinder. It’s like malloc - you can provide and link your own, and then it replaces the default one. Same with libunwind, which overrides __cxa_throw; gcc provides an internal one if you do not link libunwind.

in my case, libunwind was linked in transitively because glog specified it as a dependency. However, it is entirely optional and glog can use gcc’s internal unwinder too to read backtraces. I had to manually purge (in CMake) libunwind from the link list of my application and dynamic library targets. Then then bug is avoided because gcc’s internal unwinder is used.

@okeuday to summarize: your title is a bit wrong, gcc’s libstdc++ per se does not depend on libunwind, some other 3rd party is pulling it in (it was glog for me) and you should kick it out from being linked in. libunwind is not essential and this version just causes problems.

And my condolences for running into this :) it is truly awful

[okeuday]

@ojura Removing libunwind 1.2.1 from the compilation (with gcc/g++) does avoid the segfault. I had been hoping to keep it in the compilation because it had improved the backtrace information in the past but it looks like it is better to keep libunwind out of the compilation to keep the situation simpler and reduce the number of potential problems (it helps to ensure future reliability of CloudI source code).

Just to be clear, libstdc++ uses the libgcc unwinder which segfaults only when (nongnu) libunwind 1.2.1 is part of the compilation (and is linked to the executable) gcc/g++ creates when using optimization levels -O1 or higher. I updated the title to show that libunwind was the problem. Thank you for providing the additional information.