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 03: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?
FYI I once tried to check OSS for violations of signal handler requirements (see https://github.com/yugr/sigcheck). It turned out that many packages (ab)use malloc in sighandlers (directly or via printf et al.). Fixing (or even finding) all badly behaving software out there would be a huge amount of work so "fixing" it on the library side instead may make sense.
-Y
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |