From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-36074-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 813 invoked by alias); 10 Aug 2015 15:49:00 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 36074
Received: (qmail 13201 invoked from network); 10 Aug 2015 15:48:57 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS autolearn=ham
	autolearn_force=no version=3.4.0
X-AuditID: cbfec7f4-f79c56d0000012ee-91-55c8c7e6a1d4
Date: Mon, 10 Aug 2015 16:48:52 +0100
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: Wait test failure
Message-id: <20150810164852.0e5934f4@pwslap01u.europe.root.pri>
In-reply-to: <20150810161817.080bcdee@pwslap01u.europe.root.pri>
References: <20150808200521.4e3c85d1@ntlworld.com>
 <loom.20150810T091202-541@post.gmane.org>
 <20150810135050.7b8499e2@pwslap01u.europe.root.pri>
 <20150810161817.080bcdee@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+NgFjrALMWRmVeSWpSXmKPExsVy+t/xK7rPjp8INVh328riYPNDJgdGj1UH
	PzAFMEZx2aSk5mSWpRbp2yVwZfTe/MBeMIOz4vHKDrYGxt9sXYwcHBICJhIts+q6GDmBTDGJ
	C/fWs4HYQgJLGSWO7laHsGcwSeyYGQVhb2OU+LjHD8RmEVCV6Jt4ghXEZhMwlJi6aTYjiC0i
	IC5xdu15FhBbWEBO4sSRXWBxXgF7iYV7PzKD2JwCDhKn3ixkh5h5ilGi96cQiM0voC9x9e8n
	Joh77CVmXjkD1Sso8WPyPbCZzAJaEpu3NbFC2PISm9e8ZYaYoy5x4+5u9gmMQrOQtMxC0jIL
	ScsCRuZVjKKppckFxUnpuYZ6xYm5xaV56XrJ+bmbGCHh+mUH4+JjVocYBTgYlXh4Z2w+HirE
	mlhWXJl7iFGCg1lJhPfY4ROhQrwpiZVVqUX58UWlOanFhxilOViUxHnn7nofIiSQnliSmp2a
	WpBaBJNl4uCUamCUtFQqsoqPOeqs8X5arOEp7fm6vo2TN2xTNWHXTPGQ4Dkh9bS+dGpN+qM9
	Bu5HRBlWKdw+MG+xPs8bj9dnA+eYb1TNY8vWEoq2P5U6ZfdUj4jjczIsVSXyPJSuLTlclGc/
	6ZAn865rb3z3T/opu+/DHgHp1QLX5d1TWrfl/WcVi7l+Nl/LoEqJpTgj0VCLuag4EQCshUNE
	UwIAAA==

On Mon, 10 Aug 2015 16:18:17 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> 
> I'm wondering if in
> 
>   (exit 1) &
>   one=$!
>   (exit 2) &
>   two=$!
> 
> when we handle the first background process, sometimes the second has
> already exited so we use the status from that instead?  That would be
> quite serious --- and quite possibly not a new effect, just exacerbated
> by additional signal blocking.

Hmm...

Never second guess a quantity you can calculate explicitly.

Ismail, does this fix your occurrence of the problem, too?

diff --git a/Src/signals.c b/Src/signals.c
index 697c4c5..78dc75b 100644
--- a/Src/signals.c
+++ b/Src/signals.c
@@ -528,8 +528,14 @@ wait_for_processes(void)
 	 * and is not equal to the current foreground job.
 	 */
 	if (jn && !(jn->stat & (STAT_CURSH|STAT_BUILTIN)) &&
-	    jn - jobtab != thisjob)
-	    addbgstatus(pid, (int)lastval2);
+	    jn - jobtab != thisjob) {
+	    int val = (WIFSIGNALED(status) ?
+		   0200 | WTERMSIG(status) :
+		   (WIFSTOPPED(status) ?
+		    0200 | WEXITSTATUS(status) :
+		    WEXITSTATUS(status)));
+	    addbgstatus(pid, val);
+	}
     }
 }