Re: PATCH: job control debug

[Peter Stephenson <p.stephenson@samsung.com>]

On Thu, 6 Sep 2018 20:18:14 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> In particular entersubsh() does some juggling of SIGTTOU -- which I
> think predates this bug appearing, but there may be an interaction of
> that with some later change.

That's definitely a good tip.  We usually get here:

    if (!job_control_ok) {
	/*
	 * If this process is not going to be doing job control,
	 * we don't want to do special things with the corresponding
	 * signals.  If it is, we need to keep the special behaviour:
	 * see note about attachtty() above.
	 */
	signal_default(SIGTTOU);
	signal_default(SIGTTIN);
	signal_default(SIGTSTP);
    }

Sure enough, disabling this stops the problem happening.  Note this is
not the case where there is no job control at all --- that's a separate
test.  This is if we think we can't do job control in the current
subprocess even if we could in the parent.

What do you think of the following?  If we are in list_pipe_job land, aka
Rimmerworld, and we're attached to the terminal, keep the current signal
behaviour.

My best guess about what's changed is a newly exposed race.

diff --git a/Src/exec.c b/Src/exec.c
index 09ee132..4861ae5 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -1029,6 +1029,13 @@ entersubsh(int flags)
 		setpgrp(0L, jobtab[list_pipe_job].gleader);
 		if (!(flags & ESUB_ASYNC))
 		    attachtty(jobtab[thisjob].gleader);
+	    } else if (gettygrp() == GETPGRP()) {
+		/*
+		 * There are races where if the process is attached
+		 * to the terminal blocking SIGTTOU causes errors.
+		 * So just leaves signals alone.
+		 */
+		job_control_ok = 1;
 	    }
 	}
 	else if (!jobtab[thisjob].gleader ||

pws