This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 01/26/2016 04:14 PM, Florian Weimer wrote:
On 01/26/2016 01:44 PM, Szabolcs Nagy wrote:On 26/01/16 00:25, Joern Engel wrote:With signals we can reenter the thread-cache. Protect against that with a lock. Will almost never happen in practice, it took the company five years to reproduce a similar race in the existing malloc. But easy to trigger with a targeted test.why do you try to make malloc as-safe? isn't it better to fix malloc usage in signal handlers?We have functionality like dprintf, syslog, backtrace, C++ thread-local object access which might be used from signal handlers, but which can call malloc.
Right. One can argue that this is an error and someone should go fix the code but in my experience most real-world signal handlers have these problems and noone is going to rewrite them any time soon.
Fixing this in malloc may seem attractive, but I doubt it can be made completely reliable by concentrating changes there. Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |