Re: (potential regression in 5.0.3)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 23,  2:06am, Paul Ackersviller wrote:
}
} I've ran across something else that first looked like a regression,
} but upon further inspection Test/A05execution.ztst was doing this
} for a couple of months.  Strangely, it goes into an infinite loop,
} but only when run in the background.  It does this for me on both
} Linux and FreeBSD, starting from the commit
} c3114a7735c85b79771e08bd156470bde1a36950, but on 5.0.2 too.

It's a known issue that changing the MONITOR option from off to on
can cause the acquire_pgrp() routine to go into an infinite loop,
depending on the shape of the process tree from the foreground.
The jobs.c diff in c3114a7 partly fixed that, but the new A05execution
test needs setopt MONITOR to create the conditions it is regressing,
so it is still possible for that to trigger a loop.

Here's an attempt to resolve the remaining infinite-loop condition:

diff --git a/Src/jobs.c b/Src/jobs.c
index a321172..8719465 100644
--- a/Src/jobs.c
+++ b/Src/jobs.c
@@ -2619,6 +2619,7 @@ acquire_pgrp(void)
     sigset_t blockset, oldset;
 
     if ((mypgrp = GETPGRP()) > 0) {
+	long lastpgrp = mypgrp;
 	sigemptyset(&blockset);
 	sigaddset(&blockset, SIGTTIN);
 	sigaddset(&blockset, SIGTTOU);
@@ -2639,6 +2640,9 @@ acquire_pgrp(void)
 	    if (read(0, NULL, 0) != 0) {} /* Might generate SIGT* */
 	    signal_block(blockset);
 	    mypgrp = GETPGRP();
+	    if (mypgrp == lastpgrp && !interact)
+		break; /* Unlikely that pgrp will ever change */
+	    lastpgrp = mypgrp;
 	}
 	if (mypgrp != mypid) {
 	    if (setpgrp(0, 0) == 0) {