Subject: Re: malloc writing to fd 2
To: David Laight <firstname.lastname@example.org>
From: Noriyuki Soda <email@example.com>
Date: 07/18/2003 07:21:33
>>>>> On Thu, 17 Jul 2003 22:44:58 +0100, David Laight <firstname.lastname@example.org> 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?),
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: <email@example.com>
: From: Andrew Gierth (firstname.lastname@example.org)
: Subject: Re: siglongjmp not async-signal-safe?
: Newsgroups: comp.unix.programmer
: 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.