[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pádraig Brady
Subject: Re: [Bug-tar] Crash in gettext() after fork() on Mac OS X
Date: Sat, 23 Nov 2013 18:12:04 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

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] <>
>> 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] <>
>>   [2] <>
>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]