-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Service Arch
-
ALL
-
N&O Prioritized List
The signal handling code uses a special ostream that avoids allocating when we collect stacktraces/unwind the stack when handling a fatal signal, like SIGSEGV. This is because it is unsafe to call malloc from within a signal handler; it is not an async-signal-safe function. It is further dangerous because, if we are handling SIGSEGV and the heap state is already corrupted, we are more likely to encounter another SIGSEGV when attempting to access to allocator/heap again, possibly resulting in a fatal deadlock.
However, the boost::logging infrastructure we rely on will itself try and allocate when we go to dump out the ostream we've collected (Containing the stack trace) to the log. This can result in all the unsafe behavior discussed above, and could prevent the stacktrace from being logged and the process from exiting until it is forcefully killed.
- related to
-
SERVER-83271 Make synchronous signal handlers signal-safe
- Open
-
SERVER-82459 Fall back to default signal handler when a thread receives two signals
- Closed