GNU bug report logs -
#15970
[Bug-tar] Crash in gettext() after fork() on Mac OS X
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Mon, 25 Nov 2013 00:11:02 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 (text/x-patch, attachment)]
This bug report was last modified 11 years and 180 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.