From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24523 invoked by alias); 16 Sep 2016 16:58:05 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39362 Received: (qmail 8889 invoked from network); 16 Sep 2016 16:58:05 -0000 X-Qmail-Scanner-Diagnostics: from mailout2.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(210.118.77.12):SA:0(-2.3/5.0):. Processed in 0.539963 secs); 16 Sep 2016 16:58:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f2-f79556d000002c42-b4-57dc22393b61 Date: Fri, 16 Sep 2016 17:47:46 +0100 From: Peter Stephenson To: Zsh Hackers' List Subject: Re: Another bug when suspending pipelines Message-id: <20160916174746.1fdfae6d@pwslap01u.europe.root.pri> In-reply-to: <20160916133302.1f447ca0@pwslap01u.europe.root.pri> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsWy7djP87qWSnfCDTY8VrA42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGR9etzEVHJao+Nim1sA4T6iLkZNDQsBE4t/BiYwQtpjEhXvr 2boYuTiEBJYySqzfc4wdwullkpiyYz0LTEf714dQiWWMElM37WOBcKYxSRw8/okJpEpI4Ayj xP8OO4jEWUaJX9d3MIMkWARUJRZOu8cKYrMJGAJ1zwZazsEhIqAt0f5RDCQsLGAkMatvJdgc XgF7iX/f17CB2JwCDhIfjp0Ci/ML6Etc/QuxSwKoZuaVM4wQ9YISPybfA7uUWUBHYtu2x+wQ trzE5jVvmUHukRD4zyZxbXEHE8heCQFZiU0HmCHmuEgcX74dGhbCEq+Ob2GHsGUkLk/uhvq+ n1HiSbcvxJwZjBKnz+xgg0hYS/TdvsgIsYxPYtK26cwQ83klOtqEIEwPiacdzhDVjhLzj51m nMCoOAvJ1bOQXD0LydULGJlXMYqklhbnpqcWG+sVJ+YWl+al6yXn525iBKaA0/+Of9rB+PWE 1SFGAQ5GJR7eBbx3woVYE8uKK3MPMUpwMCuJ8F6QAwrxpiRWVqUW5ccXleakFh9ilOZgURLn 3bPgSriQQHpiSWp2ampBahFMlomDU6qBcT3HQq6qxQnSU7UKrqme9FZW9RFNDJRMTLLZ+DnV YO7/zBPpom/1p/QtkA87oWUvOb91weQ5l+LlTecd9jrQlBfLkhN5zNHh3H4DZl+fg3kB0s2Z zqGlkTlWumeYHf8/9+irbm+rOH7YvFX+/a3zkTP5O2XlHHs8XU/OlbKI+ml8Tb9HRlCJpTgj 0VCLuag4EQDemTms/QIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsVy+t/xy7qcSnfCDf5skLE42PyQyYHRY9XB D0wBjFFuNhmpiSmpRQqpecn5KZl56bZKoSFuuhZKCnmJuam2ShG6viFBSgpliTmlQJ6RARpw cA5wD1bSt0twy/jwuo2p4LBExcc2tQbGeUJdjJwcEgImEu1fH7JD2GISF+6tZ+ti5OIQEljC KPH31w1mCGcGk8S+pxOYIJxzjBIbLt1gh3DOMkq8nHmAEaSfRUBVYuG0e6wgNpuAocTUTbOB 4hwcIgLaEu0fxUDCwgJGErP6VjKB2LwC9hL/vq9hA7E5BRwkPhw7BRYXAopf2j8FbCS/gL7E 1b+fmCDOs5eYeeUMI0SvoMSPyfdYQGxmAS2JzduaWCFseYnNa94yQ8xRl7hxdzf7BEbhWUha ZiFpmYWkZQEj8ypGkdTS4tz03GIjveLE3OLSvHS95PzcTYzAGNp27OeWHYxd74IPMQpwMCrx 8Hpw3wkXYk0sK67MPcQowcGsJMJ7QQ4oxJuSWFmVWpQfX1Sak1p8iNEUGC4TmaVEk/OB8Z1X Em9oYmhuaWhkbGFhbmSkJM479cOVcCGB9MSS1OzU1ILUIpg+Jg5OqQbGxtq7/Bdl4g5fnut1 fOEqt/j8VuYz+8JLHV1/bLGUPc5k9JVjomGwj5g613LOFPXeWDW5O8kXlyyw0DJQCbGWK774 Zo+fxMcAm8SDVX+yTv7czLKIt0bC5pLRvB2RG/57Nmp9W/HR5P3lw6d0JszYNjf255PEx4a8 TPMfrdGr4llX/nPi9DIOJZbijERDLeai4kQAR0NGhLcCAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20160916164752eucas1p1add32b4825e126def7b3317c07731342 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUb?= =?UTF-8?B?7IK87ISx7KCE7J6QG1ByaW5jaXBhbCBFbmdpbmVlciwgU29mdHdhcmU=?= X-Global-Sender: =?UTF-8?B?UGV0ZXIgU3RlcGhlbnNvbhtTQ1NDLURhdGEgUGxhbmUbU2Ft?= =?UTF-8?B?c3VuZyBFbGVjdHJvbmljcxtQcmluY2lwYWwgRW5naW5lZXIsIFNvZnR3YXJl?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDA1Q0QwNTAwNTg=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20160916164752eucas1p1add32b4825e126def7b3317c07731342 X-RootMTR: 20160916164752eucas1p1add32b4825e126def7b3317c07731342 References: <20160916133302.1f447ca0@pwslap01u.europe.root.pri> On Fri, 16 Sep 2016 13:33:02 +0100 Peter Stephenson wrote: > To check my code for the other pipeline suspending problem, I came up > with a command designed to check different cases, in particular where > the left of the pipeline was still running: > > (sleep 5; print foo) | { sleep 5; read bar; print $bar; } > > Suspending this sometimes doesn't work: the ^Z is delayed and gets > relayed to the parent shell. I've had trouble getting this to happen again, so it looks like it's quite an obscure race. It's not necessarily directly related to list_pipe's Wirkung, in either English, German or Old Norse. > Sometimes even if it suspends, it stops again when you fg it, then > the second fg allows it to complete. This is much easier to reproduce, and it looks like it's related, serendipitously, to the condition I fixed earlier today --- the forked zsh can be stopped too many times because it's in the same process groups as the other stuff. I've now run out of reasons why it should be in the same process group at all, so this extends the other fix until we find out why... pws diff --git a/Src/exec.c b/Src/exec.c index 0755d55..9a7234e 100644 --- a/Src/exec.c +++ b/Src/exec.c @@ -1710,39 +1710,23 @@ execpline(Estate state, wordcode slcode, int how, int last1) break; } else { - Job pjn = jobtab + list_pipe_job; close(synch[0]); entersubsh(ESUB_ASYNC); /* * At this point, we used to attach this process * to the process group of list_pipe_job (the * new superjob) any time that was still available. - * That caused problems when the fork happened - * early enough that the subjob is in that - * process group, since then we will stop this - * job when we signal the subjob, and we have - * no way here to know that we shouldn't also - * send STOP to itself, resulting in two stops. - * So don't do that if the original - * list_pipe_job has exited. + * That caused problems in at least two + * cases because this forked shell was then + * suspended with the right hand side of the + * pipeline, and the SIGSTOP below suspended + * it a second time when it was continued. * - * The choice here needs to match the assumption - * made when handling SUBLEADER above that the - * process group is our own PID. I'm not sure - * if there's a potential race for that. But - * setting up a new process group if the - * superjob is still functioning seems the wrong - * thing to do. + * It's therefore not clear entirely why you'd ever + * do anything other than the following, but no + * doubt we'll find out... */ - if (pjn->procs && - (pjn->stat & STAT_INUSE) && - !(pjn->stat & STAT_DONE)) { - if (setpgrp(0L, mypgrp = jobtab[list_pipe_job].gleader) - == -1) { - setpgrp(0L, mypgrp = getpid()); - } - } else - setpgrp(0L, mypgrp = getpid()); + setpgrp(0L, mypgrp = getpid()); close(synch[1]); kill(getpid(), SIGSTOP); list_pipe = 0;