Re: Is malloc signal-"tolerant"?

[Wolfram Gloger]

> But is malloc signal-"tolerant" in that its internal data structures
> survive a longjmp() (or a siglongjmp()) out of a signal handler?

Not currently in glibc.

> Given this program, for instance, which basically exercises malloc and
> free in a very tight loop,
..
> that essentially keeps signalling to the test program - should this
> survive?

I don't know whether it should survive, but I've just tested it
with the prerelease snapshot of ptmalloc2,

http://www.malloc.de/malloc/ptmalloc2.tar.gz

which has inline spinlocks (instead of pthreads mutexes) for ix86 (and
only ix86 at the moment).  This is something that I want to enable for
the next glibc release, too (not necessarily because they're more
signal safe, but because of better performance).

Testing your program has revealed that rand() isn't singal-"tolerant"
either - after some time, it returns bogus huge values.  But after
removing rand(), your test program survived for quite some time, when
I linked with malloc.o from ptmalloc2.  However, signalling causes a
memory leak, because some free()s are never executed to completion.
So, such an interruption would have to remain a rare event.

> [This would imply that the for the duration of a malloc operation,
> certain signals are blocked - I cannot imagine any other way to
> guarantee signal-atomic operations.]

Signal-safe spinlocks are an alternative.  Blocking a signal in every
malloc() would be _way_ too costly.

Regards,
Wolfram.