[Top][All Lists]

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

[bug-gettext] Crash in gettext() after fork() on Mac OS X

From: Guillem Jover
Subject: [bug-gettext] Crash in gettext() after fork() on Mac OS X
Date: Sat, 23 Nov 2013 04:38:03 +0100
User-agent: Mutt/1.5.21 (2010-09-15)


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.

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?


reply via email to

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