[SERVER-83271] Make synchronous signal handlers signal-safe Created: 15/Nov/23  Updated: 07/Dec/23

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Ryan Berryhill Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-82658 Log system will attempt to allocate i... Open
is related to SERVER-66562 Audit, document all functions accesse... Backlog
is related to SERVER-82459 Fall back to default signal handler w... Closed
Assigned Teams:
Service Arch
Operating System: ALL
Sprint: Service Arch Prioritized List
Participants:

 Description   

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.


Generated at Thu Feb 08 06:51:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.