[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: Eric Blake
Subject: Re: [Bug-tar] Crash in gettext() after fork() on Mac OS X
Date: Sat, 23 Nov 2013 07:30:22 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

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

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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