Subject: Re: malloc writing to fd 2
To: David Laight <david@l8s.co.uk>
From: Noriyuki Soda <soda@sra.co.jp>
List: tech-userlevel
Date: 07/18/2003 07:21:33
>>>>> On Thu, 17 Jul 2003 22:44:58 +0100, David Laight <david@l8s.co.uk> said:

>    The program calls exit() from within the signal handler (probably
>    technically illegal)

Yes, it's illegal. (although calling _exit() is legal.)

> Even if the code used longjump() to escape the signal handler, which is
> supposed to be ok (isn't it?),

It depends.
And in this case, it is NOT OK, because one of atexit() handler
indirectly calls malloc(3), and malloc(3) isn't async-signal-safe.

i.e. malloc(3) doesn't block signals, thus, the program you saw
will not work, even if malloc(3) doesn't call vasprintf().

Please read the following description, for example:

: Message-Id: <87wuhk5vj1.fsf@erlenstar.demon.co.uk>
: From: Andrew Gierth (andrew@erlenstar.demon.co.uk)
: Subject: Re: siglongjmp not async-signal-safe?
: Newsgroups: comp.unix.programmer
	[snip]
: see the "APPLICATION USAGE" section for sigaction() where this is
: specifically addressed.
: 
: If you longjmp (via either longjmp or siglongjmp) out of a signal
: handler that has interrupted an async-signal-unsafe function, then for
: the remainder of the program's execution, the results of calling any
: async-signal-unsafe function is undefined.
: 
: You can safely longjmp out of a signal handler (or call any other
: unsafe function for that matter) only if you know that the signal did
: not interrupt an unsafe function (usually the only way to know this is
: to keep the signal blocked except in regions known to be safe).

> then the malloc() code is still well and trully stuffed - especially
> if THREAD_LOCK() is defined.

THREAD_LOCK() means that malloc(3) is MT-safe, not async-signal-safe.
--
soda