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

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

The following reply was made to PR bin/48875; it has been noted by GNATS.

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/48875 CVS commit: [netbsd-9] src/bin/sh
Date: Wed, 28 Apr 2021 09:58:43 +0000

 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.