KjellKod
commented
1 year ago Hi
Unfortunately. Once a crash has happened it's in undefined state and even extracting stackdump information isn't defined.
It's exceedingly rare to hit your specific situation but yes, it can happen.
G3log can have it's signal handling turned off. Please see the documentation for this
These might be of interest to you also: https://stackoverflow.com/questions/42425767/can-malloc-failure-cause-deadlock-or-cause-race-condition#42425795
https://stackoverflow.com/questions/855763/is-malloc-thread-safe
When we were troubleshooting our own program crash issue, we encountered an issue that g3log's LogCapture could cause the program to deadlock rather than crash and print stack information. It seems like our program crashed while called a function,which use malloc to allocate memory.However,the destructor of LogCapture also called the malloc function when signalhandler is triggered, ultimately resulting in a deadlock and the program can not exit. Here is the information about GDB backtrace： 0 0x0000007f969fdffc in __lll_lock_wait_private ( futex=futex@entry=0x7f96a74a70) at ./lowlevellock.c:33
1 0x0000007f96998434 in __GI___libc_malloc (bytes=208) at malloc.c:3073
2 0x0000007f96b6c52c in operator new(unsigned long) ()
from /usr/lib/aarch64-linux-gnu/libstdc++.so.6
3 0x000000557613ba30 in g3::internal::saveMessage(char const, char const, int, char const, LEVELS const&, char const, int, char const*) ()
4 0x000000557613c928 in LogCapture::~LogCapture() ()
5 0x000000557614af2c in (anonymous namespace)::signalHandler(int, siginfo_t, void) ()
6
7 _int_malloc (av=av@entry=0x7f96a74a70, bytes=bytes@entry=390656)
8 0x0000007f96998444 in __GI___libc_malloc (bytes=390656) at malloc.c:3075
9 0x0000007f96b6c52c in operator new(unsigned long) ()
from /usr/lib/aarch64-linux-gnu/libstdc++.so.6