[debbugs-tracker] bug#15970: closed ([Bug-tar] Crash in gettext() after fork() on Mac OS X)

[GNU bug Tracking System]

Your message dated Tue, 26 Nov 2013 12:23:15 +0000
with message-id <address@hidden>
and subject line Re: bug#15970: [Bug-tar] Crash in gettext() after fork() on 
Mac OS X
has caused the debbugs.gnu.org bug report #15970,
regarding [Bug-tar] Crash in gettext() after fork() on Mac OS X
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
15970: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15970
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: [Bug-tar] Crash in gettext() after fork() on Mac OS X
>
>
>
>
> Date: 
>
> Sun, 24 Nov 2013 16:10:16 -0800
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
>
>
>
>
> Eric Blake wrote:
> > I bet coreutils' sort has a similar bug
>
> [Adding bug-coreutils to the CC:.]
>
> Coreutils 'sort' runs into this problem only
> if dup2 fails when called from move_fd_or_die
> or if execlp fails.
>
> dup2 should never fail when it's called
> the way that 'sort' calls it.  So perhaps
> 'sort' should be simplified to call dup2
> and discard its return value.
>
> And when execlp fails, 'sort' could _exit
> with a special value, so that the parent
> could report the failure.
>
>
>
> --- End Message ---

--- Begin Message --- Subject: Re: bug#15970: [Bug-tar] Crash in gettext() after fork() on Mac OS X Date: Tue, 26 Nov 2013 12:23:15 +0000 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 11/26/2013 04:55 AM, Paul Eggert wrote:
> Pádraig Brady wrote:
> 
>> How about the attached instead that just uses
>> a somewhat degraded but simpler error() equivalent.
> 
> That looks safe, though it could be simplified:
> use inttostr instead of repeating its body,

Hah, I was thinking this must be done somewhere else :)

> and since !!p == !!errnum there's no need
> to have those duplicate conditions.

I meant to use (p || errstr), but let's assume
errstr is present, so yes we can then remove condition.

> Plus, just use STDERR_FILENO rather than
> fiddling with fileno (stderr),

done

> and async_safe_error
> should be _Noreturn and should unconditionally call
> _exit.

fair enough. I changed the name so to async_safe_die()

> And, I wouldn't bother looking at dup2's
> return value, any more than we look at close's.

Updated patch attached.

thanks!
Pádraig.

sort-async-safe.patch
Description: Text Data

--- End Message ---