Closed nmaludy closed 2 years ago
FYI looks like this was causing by the signal handler being called recursively from another malloc()
call that raised SIGSEGV'd
#36 <signal handler called>
--Type <RET> for more, q to quit, c to continue without paging--
#37 0x00007f6fbf3f0a4f in raise () from /lib64/libc.so.6
#38 0x00007f6fbf3c3db5 in abort () from /lib64/libc.so.6
#39 0x00007f6fbf433057 in __libc_message () from /lib64/libc.so.6
#40 0x00007f6fbf43a1bc in malloc_printerr () from /lib64/libc.so.6
#41 0x00007f6fbf43babc in _int_free () from /lib64/libc.so.6
#42 0x00007f6f8071ade5 in osgeo::proj::common::UnitOfMeasure::~UnitOfMeasure() () from /usr/proj82/lib/libproj.so.22
#43 0x00007f6fbf3f31ec in __run_exit_handlers () from /lib64/libc.so.6
#44 0x00007f6fbf3f3320 in exit () from /lib64/libc.so.6
#45 0x00007f6fbf3dccaa in __libc_start_main () from /lib64/libc.so.6
#46 0x000000000040154e in _start ()
Problem appears to be in the shutdown of the proj
library. Not sure why yet.
Closing since it's not a problem with backward-cpp
You either have a memory corruption. Which happens to mutate some malloc data. Or the wrong pointer to free. Or maybe even a double free. The next call to malloc (_int_free()
) appears to abort the program. Which most likely leaves the malloc mutex locked behind. Then, when trying to print the trace, libdw
calls malloc. Which deadlocks.
Working with
backward
and in most cases it handles printing our stack traces just fine. However, in one of our applications (for some reason) it seems to hang when resolving the stack trace usinglibdw
. It appears thatlibdw
is allocating some memory causing a deadlock within the signal handler. Below is the backtrace fromgdb
.Any ideas on what could cause this? I'm happy to help provide info and help fix the issue.