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

[Pádraig Brady]

On 11/25/2013 12:10 AM, Paul Eggert wrote:
> Eric Blake wrote:
>> I bet coreutils' sort has a similar bug
> 
> [Adding bug-coreutils to the CC:.]

Referencing the original coreutils thread from the new bug:
http://lists.gnu.org/archive/html/coreutils/2013-11/msg00083.html

> Coreutils 'sort' runs into this problem only
> if dup2 fails when called from move_fd_or_die
> or if execlp fails.

Right.

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

For both cases we could _exit(errno),
which the parent would get with waitpid().

Interestingly, currently the parent only
notices an error after stdio eventually issues a write(),
at which point the parent receives SIGPIPE and
exits with status 141 (128 + SIGPIPE).

If instead the parent caught sigchld it
could waitpid() to get the status more directly.
Though there are various gotchas with sigchld handling,
and we'd have to handle the reap() error() calls
outside of the signal handler.  This would also be
the case if we wanted to reap on SIGPIPE.
So at first glance this seems to be a bit overcomplicated
for what it's solving.

How about the attached instead that just uses
a somewhat degraded but simpler error() equivalent.

thanks,
Pádraig.

sort-async-safe.patch
Description: Text Data