-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Service Arch
-
ALL
-
SP Prioritized List
-
(copied to CRM)
In https://github.com/mongodb/mongo/blob/8e4b5670df9b9fe814e57cb5f3f8ee9407237b5a/src/mongo/util/signal_handlers_synchronous.cpp , the server defines signal-handlers for a variety of signals that can be synchronously generated, like SIGSEGV and SIGABRT. The signal-handling action for these signals is defined to be some version of logging a fatal error, collecting and logging a backtrace, and the exiting. Today, this includes some known signal-unsafe behavior, such as use of mutex as described in this comment. This can result in potential deadlocks when handling a signal.
It can block other signals from being effectively processed, because the mutex is held by another signal-handler invocation. This means that if an i.e. invariant fires in the server while another signal-handler has gotten stuck, the abort raised by the invariant will never be processed.
- is related to
-
SERVER-82658 Log system will attempt to allocate inside of signal handler
- Open
-
SERVER-82459 Fall back to default signal handler when a thread receives two signals
- Closed
-
SERVER-66562 Audit, document all functions accessed by sync signal handlers
- Backlog
- related to
-
SERVER-90775 libunwind deadlocks when called from signal handler while dl_iterate_phdr is running
- Blocked