realloc/free async-signal safe?

[Kurt Miller]

On Wednesday 16 September 2009 02:19:14 pm Kurt Miller wrote:
> Hi,
> 
> I've looked over the malloc/realloc/free implementation and understand
> its use of arena's with trylock to avoid lock contention. However, it wasn't
> clear to me if the algorithm is truly async-signal safe or not.
> 
> Is glibc-2.5's realloc/free implementation async-signal safe?

After a closer look at the realloc and free implementation I can see that
they are not fully async-signal safe.

If the orignal allocation was not mmapped (i.e. smaller then mmap_threshold
or if n_mmaps_max had been exceeded), then arena locking is required.
The use of locking makes both  realloc and free not async-signal safe.

The original reason for my inquiry was because I noticed functions required
to be async-signal safe by POSIX are utilizing realloc and free. In particular
execle() was changed away from alloca to realloc in revision 1.10. The
likely-hood of all the events required to happen at the same time are extremely 
unlikely (free locked in same arena, signal or fork in mt app, execle with > 2048
args, n_mmaps_max exceeded). However, alloca is clearly async-signal safe
doesn't require deeper inspection and doesn't suffer from a rare deadlock or
arena memory corruption.

Unless I've missed something in my analysis, functions required to be
async-signal safe need to avoid realloc and free even using ptmalloc2.

Regards,
-Kurt