Thought I'd post this here, this is the reply from the dpkg author that I have
been trying to fix the u-a tests with. I haven't had a chance to apply and
test the patch or even look at it, but I hope to do so this week.
Martin and thoughts or insights on this?
---
TS
http://www.southofheaven.org/
Life begins and ends with chaos, live between the chaos!
On 2013-11-03, at 8:10 PM, Guillem Jover <guil...@debian.org> wrote:
> Hi!
>
> On Fri, 2013-11-01 at 07:32:55 -0600, TheSin wrote:
>> Hey Guillem, I doubt this has anything to do with our failing tests,
>> but this is a bug i have been trying very HARD to track down that
>> just showed up on 10.9.
>
>> I have a small fix for it where I can all dpkg-dev commands with
>> LANG=C LC_ALL=C dpkg-deb
>>
>> But now that we know the real cause of these issues maybe I could
>> help go over to the code base and find all the instances of forks
>> that use gettext inline and convert them like bellow?
>
> Unfortunately there's parts of the code base that would be very
> cumbersome and unwieldy to fix, for something I consider an issue
> between gettext and CoreFoundation. And performing the proposed
> changes would result in pretty annoying code. I'll report this to
> gettext upstream.
>
>> Would you like an official bug report on this?
>
> Filing these on the Debian BTS is a sure way to guarantee they won't
> get missed or forgotten.
>
>> On 2013-11-01, at 5:15 AM, Martin Costabel <costa...@wanadoo.fr> wrote:
>>> I don't think we can do much about the behavior of gettext. As long
>>> as it uses the CoreFoundation framework, it will not be "async-signal
>>> safe", so it must not be used in the child process after a 'fork' and
>>> before 'exec'. This is documented in many places.
>
> Actually given how gettext uses the CoreFoundation framework (which I
> guess is starting other threads behind the program's back :), it seems
> to me it should be pretty safe, as long as a gettext function is
> called on the main thread.
>
> The only two places inside gettext where it calls CoreFoundation
> functions, cache their results, so if we call gettext once before the
> fork() that looks to me it should pre-initialize the cache and avoid
> the subsequent crash?
>
>>> After reading some of the docs, I find it rather astonishing that
>>> dpkg did not crash before. That it crashes when LANG is unset is
>>> less surprising than that it does not crash when LANG is set and
>>> that it waited until OSX 10.8 or 10.9 to show the crash, but
>>> understanding what the precise mechanism of the crash is would
>>> require a deep understanding of CoreFoundation's innards.
>>>
>>> I think that these are real programming errors in dpkg and tar. They
>>> should not use any '_("")' type strings in the child process after
>>> 'fork'. If they really want to transmit localized messages as
>>> parameters to some function in the child process, they should
>>> evaluate the string *before* the 'fork' and transmit a variable
>>> to the function, like so:
>
> The way I see the issue here, is that yes calling async-signal-unsafe
> functions after a fork is a problem, but not one created by dpkg,
> because that's only an issue if the program is multi-threaded, and if
> in this case the CoreFoundation framework is creating threads behind
> dpkg's back, the dpkg expectations don't hold true.
>
> In any case, could you try the attached patch, if that workarounds the
> issue for now, I'll apply something like this until a possibly fixed
> gettext is released.
>
> Thanks,
> Guillem
diff --git a/dpkg-deb/main.c b/dpkg-deb/main.c
index 28bcd7b..abfe336 100644
--- a/dpkg-deb/main.c
+++ b/dpkg-deb/main.c
@@ -216,6 +216,8 @@ int main(int argc, const char *const *argv) {
bindtextdomain(PACKAGE, LOCALEDIR);
textdomain(PACKAGE);
+ gettext("");
+
dpkg_set_progname(BACKEND);
standard_startup();
myopt(&argv, cmdinfos, printforhelp);
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
