Re: [Bug-tar] Crash in gettext() after fork() on Mac OS X

[Pádraig Brady]

On 11/23/2013 02:30 PM, Eric Blake wrote:
> [adding coreutils; coreutils' sort is probably also affected]
> 
> On 11/22/2013 08:38 PM, Guillem Jover wrote:
>> Hi!
>>
>> The fink developers tracked down [0] the source of crashes in tar
>> and dpkg on Mac OS X.
>>
>>   [0] <http://article.gmane.org/gmane.os.macosx.fink.devel/21882>
>>
>> It comes down to usage of the CoreFoundation framework through libintl
>> after a fork(), that per POSIX is specified to only support calling
>> async-signal-safe functions in case of multi-threaded programs. Which
>> is the case when using the CoreFoundation framework, but that's an
>> expectation that the program does not have, so IMO that's a problem
>> between libintl and the CoreFoundation.
> 
> Ouch.  I bet coreutils' sort has a similar bug, as we use
> non-async-signal-safe functions after forking even though sort can be a
> multi-threaded process.
> 
> It is really hard to robustly fork a multi-threaded program while still
> having nice error reporting, as you CANNOT use malloc() in the child
> (which gettext() does) until after exec.  One typical solution is to
> quit trying to report translated messages in the child, and instead open
> a pipe file descriptor for passing codes back to the parent where the
> parent then translates the error message.
> 
>>
>> As a workaround in dpkg [1], on Mac OS X, I'm adding a dummy
>> gettext("") call to guarantee that the cache gets initialized and no
>> CoreFoundation function gets invoked first after a fork(). Because
>> the solution proposed in [2] is very unappealing and unwieldy. I'm
>> guessing the same might apply for tar.
>>
>>   [1] <http://article.gmane.org/gmane.os.macosx.fink.devel/21892>
>>   [2] <http://article.gmane.org/gmane.os.macosx.fink.devel/21887>
>>
>> Given that the only two places the CoreFoundation framework is invoked
>> cache their results, and one of them (gl_locale_name_default) is through
>> the setlocale() replacement, usually called at program start; the only
>> problematic case is the _nl_language_preferences_default() instance,
>> called through guess_category_value() and DCIGETTEXT(). Do you think
>> it would be fine to call _nl_language_preferences_default() from one
>> of the libintl functions usually called from program startup time to
>> avoid those crashes on Mac OS X?
> 
> No, it's worse than just avoiding CoreFoundation.  ANY use of gettext()
> functions is prone to call malloc(), but malloc is not
> async-signal-safe, so gettext() CANNOT safely be used pre-exec in the
> fork()d child of a multi-threaded parent.
> 

So in summary we're restricted in what we can call
between fork() and exec() in the child of a multithreaded program.
A very quick look at sort.c suggests that that is only
the _("dup2 failed") call we have to worry about.
dup2() itself is async-signal-safe according to POSIX.
I'd just remove the _("") in that case.

thanks,
Pádraig.