How signal-safe is our malloc()?
Mouse <[email protected]> Fri, 14 Nov 2025 13:55:08 -0500 (EST)
| Newsgroups | gmane.os.netbsd.devel.userlevel |
|---|---|
| Message-ID | <[email protected]> |
At work, we have a program that (because of its DOS heritage) does a lot of work in signal handlers. When I first ported it from DOS to NetBSD, I converted interrupt handlers into signal handlers. Then it crashed occasionally. Digging into the crashes, it turned out that it was an Xlib call getting interrupted by a signal, with the handler making another Xlib call and colliding over some Xlib-internal data structures. So I opened a second X connection and arranged for the main line to use one of them and the "interrupt" (signal-handling) line to use the other. That stabilized it. Now, for various reasons, they are trying to move it to Linux. They're seeing crashes that look like main line -> Xlib (main-line connection) -> malloc-family call -> signal handler -> Xlib (signal-handler connection) -> malloc-family call -> boom The malloc family in use there is clearly not signal-safe. This then makes me wonder why we didn't see the same on NetBSD. signal(7) says our malloc isn't signal-safe either, but I'm wondering whether it actually is signal-safe in 9.1 and signal safety just isn't promised, or perhaps it's not signal-safe but the window of risk is much smaller, or...what? Any thoughts? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B