[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-hackers] [PATCH] Fix #1414 by not mallocing in a signal handler
From: |
Peter Bex |
Subject: |
[Chicken-hackers] [PATCH] Fix #1414 by not mallocing in a signal handler |
Date: |
Sat, 16 Sep 2017 21:21:14 +0200 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
Hi all,
Lemonboy found another stupid mistake I made; the statistical profile
calls malloc() in the middle of a signal handler. Apparently, malloc
is not reentrant and takes a global lock, which will result in deadlock
if the signal arrives while malloc() is doing its thing.
Attached are patches for master and chicken-5, I think this is simple
and serious enough to warrant a fix in master.
The fix is relatively straightforward: when profiling is active, we
pre-allocate a bucket in C_trace(), which can be consumed by the
signal handler. It takes a little bit of care, because we must
allocate before actually putting some contents into the trace buffer,
since the signal might occur in between.
A signal may occur before the next trace() call, but that's okay
because in that situation, the topmost trace buffer entry _must_ have
a corresponding bucket from taking the previous profile sample.
Essentially, trace() prepares the state for a potential profile sample
to be taken, but if that doesn't happen, the previous pre-allocation
will just sit there. The next trace() will see it and avoid
pre-allocating, so the overhead this introduces during trace is neglible.
Cheers,
Peter
0001-Pre-allocate-profile-bucket-to-avoid-malloc-in-signa.chicken-5.patch
Description: Text Data
0001-Pre-allocate-profile-bucket-to-avoid-malloc-in-signa.master.patch
Description: Text Data
signature.asc
Description: PGP signature
- [Chicken-hackers] [PATCH] Fix #1414 by not mallocing in a signal handler,
Peter Bex <=