From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26503 invoked by alias); 10 Aug 2015 17:25: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: 36079 Received: (qmail 5848 invoked from network); 10 Aug 2015 17:25:04 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=K06wX1fqTnT8r03CDkD7n5elxzH7UEJhtuZV8yUK+ZA=; b=Njxg3vmC4z2ohzYIUmezXlervyQ0gNNQ038yoZNNMpw0pKkTX1ZpLCKhBM8d8g7T6K zW7RLT8q/nxDyW4fk8y5AnUS3Qg/+bGpw+tQBsBlY9Pnwr0nLIsrjLKKR5JJ1PDgshYx aVcR3r/uB94Lqy5sXo99kENTOHialx2qUqk2iFgDfZHDxVSjH/uX2uogZKiBeNiKLNOD mdp23k9OJ88cWAfDBDW/TOg+bAhMIBymRcFLZnLe51Fv5BxVvnICLBhwr6UN8ez1lATD 3VhEP/0EWe7GGJvJa4+iUIT7d0EGcbLzvA5mtz5u4VuFN1LfHT5UuJML3ybaqZ5NCo6Z TQ1A== X-Gm-Message-State: ALoCoQls+3TGO/0bMXEdFqc+rKtCg3Z/13bNcbyJTQlRrabWBzh93kq+FYA69+fPfB1RWYeuehcs X-Received: by 10.60.134.78 with SMTP id pi14mr6931880oeb.65.1439227500070; Mon, 10 Aug 2015 10:25:00 -0700 (PDT) From: Bart Schaefer Message-Id: <150810102456.ZM5834@torch.brasslantern.com> Date: Mon, 10 Aug 2015 10:24:56 -0700 In-Reply-To: Comments: In reply to Ismail Donmez "Re: 5.0.9 eventually...?" (Aug 10, 7:12am) References: <20150808200521.4e3c85d1@ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: A05 test failure (was Re: 5.0.9 eventually...?) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 10, 7:12am, Ismail Donmez wrote: } } latest git started to fail here on Linux x64: } } ./A05execution.ztst: starting. } This test takes 5 seconds to fail... } Test ./A05execution.ztst failed: bad status 2, expected 1 from: } Was testing: The status of recently exited background jobs is recorded This apparently has always been a race condition and queuing of signals in more places simply made it obvious. I can only reproduce the failed test on one of the systems where I can try it. What's happening is that the SIGCHLD for (exit 2) is arriving during the run of zhandler() for recording the status of (exit 1). The value of the global lastval2 is not saved/restored around the signal handling so when the (exit 1) handler resumes it copies the exit status of the second child into the bgstatus list as the exit of the first child. It's fairly easy to make any two of the jobs exchange status by adding sleep or other delays. Anyway, turns out this was an ANCIENT bug that the revised queueing paradigm exposed. diff --git a/Src/signals.c b/Src/signals.c index 697c4c5..acdc0bc 100644 --- a/Src/signals.c +++ b/Src/signals.c @@ -487,6 +487,12 @@ wait_for_processes(void) break; } + /* This is necessary to be sure queueing_enabled > 0 when + * we enter printjob() from update_job(), so that we don't + * decrement to zero in should_report_time() and improperly + * run other handlers in the middle of processing this one */ + queue_signals(); + /* * Find the process and job containing this pid and * update it. @@ -530,6 +536,8 @@ wait_for_processes(void) if (jn && !(jn->stat & (STAT_CURSH|STAT_BUILTIN)) && jn - jobtab != thisjob) addbgstatus(pid, (int)lastval2); + + unqueue_signals(); } } -- Barton E. Schaefer