CVS commit: [netbsd-9] src/bin/sh

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Wed Apr 28 09:58:43 UTC 2021

Modified Files:
        src/bin/sh [netbsd-9]: eval.c jobs.c jobs.h

Log Message:
Pull up following revision(s) (requested by kre in ticket #1259):

        bin/sh/jobs.h: revision 1.24
        bin/sh/eval.c: revision 1.182
        bin/sh/jobs.c: revision 1.110

Related to PR bin/48875

Correct an issue found by Oguz <oguzismailuysal%gmail.com@localhost> and reported
in e-mail (on the bug-bash list initially!) with the code changed to deal
with PR bin/48875

With:
         sh -c 'echo start at $SECONDS;
                        (sleep 3 & (sleep 1& wait) );
                echo end at $SECONDS'

The shell should say "start at 0\nend at 1\n", but instead (before
this fix, in -9 and HEAD, but not -8) does "start at 0\nend at 3\n"
(Not in -8 as the 48875 changes were never pulled up)>

There was an old problem, fixed years ago, which cause the same symptom,
related to the way the jobs table was cleared (or not) in subshells, and
it seemed like that might have resurfaced.

But not so, the issue here is the sub-shell elimination, which was part
of the 48875 "fix" (not really, it wasn't really a bug, just sub-optimal
and unexpected behaviour).

What the shell actually has been running in this case is:

         sh -c 'echo start at $SECONDS;
                        (sleep 3 & sleep 1& wait );
                echo end at $SECONDS'

as the inner subshell was deemed unnecessary - all its parent would
do is wait for its exit status, and then exit with that status - we
may as well simply replace the current sub-shell with the new one,
let it do its thing, and we're done...

But not here, the running "sleep 3" will remain a child of that merged
sub-shell, and the "wait" will thus wait for it, along with the sleep 1
which is all it should be seeing.

For now, fix this by not eliminating a sub-shell if there are existing
unwaited upon children in the current one.  It might be possible to
simply disregard the old child for the purposes of wait (and "jobs", etc,
all cmds which look at the jobs table) but the bookkeeping required to
make that work reliably is likely to take some time to get correct...

Along with this fix comes a fix to DEBUG mode shells, which, in situations
like this, could dump core in the debug code if the relevant tracing was
enabled, and add a new trace for when the jobs table is cleared (which was
added predating the discovery of the actual cause of this issue, but seems
worth keeping.)   Neither of these changes have any effect on shells
compiled normally.

XXX pullup -9


To generate a diff of this commit:
cvs rdiff -u -r1.175.2.2 -r1.175.2.3 src/bin/sh/eval.c
cvs rdiff -u -r1.106.2.1 -r1.106.2.2 src/bin/sh/jobs.c
cvs rdiff -u -r1.23 -r1.23.2.1 src/bin/sh/jobs.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.