Segfault when astra is linked to Easylogging++

Technical Support & Q&A Advanced
1

We have a large application with multiple dependencies. The environment is:

  • Ubuntu 16.04 LTS
  • Intel® Core™ i7-7700HQ CPU @ 2.80GHz × 8
  • AstraSDK-v2.0.9-beta3-dc1f53e9c9-20180623T013908Z-Linux

When we linked to astra_core.so, a segfault appeared at the very start of execution. Backtracking indicated the issue happened inside astra_core.so, and linked to the logging process.

After further investigation, it seemed the issue is easylogging++, which very likely was used in astra_core.so. Following that line, I managed to reproduce a minimal example using easylogging++, which is here attached. The two files easylogging++.cc and easylogging++.h come directly from GitHub - amrayn/easyloggingpp: Single header C++ logging library. It is extremely powerful, extend (tag v9.96.4).

The example is a small variation of the sample ColorReaderEventCPP with an option to link against easylogging++. If you build as follows:

cd ColorReaderEventCPP-Logging
mkdir build
cd build
cmake ..
make
./ColorReaderEventCPP-Logging

then it should be exactly the same as ColorReaderEventCPP and everything should work well. Please note, ASTRA_ROOT needs to be defined with the astra sdk folder.

However, if you now build as follows:

cd ColorReaderEventCPP-Logging
mkdir build
cd build
cmake -DTEST_EASYLOGGING=ON ..
make
./ColorReaderEventCPP-Logging

Then a segfault will appear.

This is an important issue, as it seems astra_core is blocking end user applications from using similar logging strategies, and for us is a blocking point, as we are linking against other 3rd party libraries which are also closed, and using similar logging strategies.

2

It seems the forum does not allow to attach files. Here is the example:

3

I’m seeing a similar problem with the recent 2.1.3 Astra SDK on ubuntu: (I use spdlog within my own apps, not sure if relevant); immediately upon running the app, I get:

Segmentation fault (core dumped)

and this is the backtrace from gdb:

#0  0x00007fffb1dbbad1 in  () at /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6971b4d in std::_Hashtable<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::__detail::_Select1st, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::clear() (this=0xbb5e28) at /usr/include/c++/9/bits/hashtable_policy.h:2120
#2  std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::clear() (this=0xbb5e28) at /usr/include/c++/9/bits/unordered_map.h:843
#3  el::base::utils::CommandLineArgs::setArgs(int, char**) (this=0xbb5e10, argc=0, argv=0x0) at ./third-party/easyloggingpp/src/easylogging++.cc:1340
#4  0x00007fffb45afd6d in el::base::Storage::Storage(std::shared_ptr<el::LogBuilder> const&) () at /opt/AstraSDK/lib/libastra_core.so
#5  0x00007fffb459e24e in _GLOBAL__sub_I_astra_context_impl.cpp () at /opt/AstraSDK/lib/libastra_core.so

the samples build and execute fine, so I’m assuming something in the astra sdk is trying to initialize logging and parse the command line.
back to the old OpenNI2 library support…it seems like the ROS package still uses that