bug-bash
[Top][All Lists]
Advanced

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

Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'


From: Harald van Dijk
Subject: Re: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'
Date: Sat, 8 Feb 2020 18:39:38 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Thunderbird/73.0

On 07/02/2020 02:41, Robert Elz wrote:
     Date:        Thu, 6 Feb 2020 16:12:06 +0000
     From:        Martijn Dekker <address@hidden>
     Message-ID:  <address@hidden>

   | NetBSD sh behaves differently. NetBSD 8.1 sh (as installed on sdf.org
   | and sdf-eu.org) seem to act completely normally, but NetBSD 9.0rc2 sh
   | (on my VirtualBox test VM) segfaults. Output on NetBSD 9.0rc2:

I have updated my opinion on that, I think it is "don't have the bug",
though it is possible a blocked SIGCHLD acts differently on NetBSD than
on other systems.   On NetBSD it seems to affect nothing (the shell does
not rely upon receiving SIGCHLD so not getting it is irrelevant) and
the wait code when given an arg (as your script did) would always wait
until that process exited, and return as soon as it did.

I think you're right that this isn't SIGCHLD behaving differently on NetBSD, it's that NetBSD sh does not have the same problem the other ash-based shells do. The problem is with sigsuspend, which in dash looks like:

                sigblockall(&oldmask);

                while (!gotsigchld && !pending_sig)
                        sigsuspend(&oldmask);

                sigclearmask();

<https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/jobs.c?id=f30bd155ccbc3f084bbf03d56f9cc43f4b02af2a#n1170>

This clearly cannot work when oldmask blocks SIGCHLD.

NetBSD sh does not use sigsuspend here, so avoids that problem.

I changed gwsh to call sigclearmask() on shell startup, but plan to check whether this loop is really necessary at some later time. It was added to dash to fix a race condition, where that race condition was apparently introduced by a fix for another race condition. If NetBSD sh manages to avoid this pattern, and assuming NetBSD sh is not still susceptible to one of those race conditions, the fix for it in the other shells would seem to be more complicated than necessary, and simplifying things would be good.

Cheers,
Harald van Dijk



reply via email to

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