[SERVER-82658] Log system will attempt to allocate inside of signal handler Created: 01/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: George Wangensteen 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
related to SERVER-83271 Make synchronous signal handlers sign... Open
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   

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.



 Comments   
Comment by Billy Donahue [ 01/Nov/23 ]

I don't think so.

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