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]

Re: [PATCH] malloc: add locking to thread cache


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]