From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19068 invoked by alias); 16 Feb 2017 20:18:20 -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: 40563 Received: (qmail 1417 invoked from network); 16 Feb 2017 20:18:20 -0000 X-Qmail-Scanner-Diagnostics: from lorien.comfychair.org 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(173.8.144.98):SA:0(-0.0/5.0):. Processed in 2.162606 secs); 16 Feb 2017 20:18:20 -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=-0.0 required=5.0 tests=RP_MATCHES_RCVD,SPF_HELO_PASS, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: duvall@lorien.comfychair.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at lorien.comfychair.org designates 173.8.144.98 as permitted sender) Date: Thu, 16 Feb 2017 12:18:07 -0800 From: Danek Duvall To: Peter Stephenson Cc: zsh-workers@zsh.org Subject: Re: signal mask bug? Message-ID: <20170216201807.GA3274@lorien.comfychair.org> Mail-Followup-To: Danek Duvall , Peter Stephenson , zsh-workers@zsh.org References: <20170215221757.GA24355@lorien.comfychair.org> <170215201044.ZM15764@torch.brasslantern.com> <20170216094836.7db14518@pwslap01u.europe.root.pri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170216094836.7db14518@pwslap01u.europe.root.pri> User-Agent: Mutt/1.5.20 (2010-04-22) On Thu, Feb 16, 2017 at 09:48:36AM +0000, Peter Stephenson wrote: > On Wed, 15 Feb 2017 20:10:44 -0800 > Bart Schaefer wrote: > > But then when we reach prinjob() from the "jobs" command, pn->status of > > that job has changed from -1 to 65535. > > > > This happens at signals.c:525 in wait_for_processes(), when the status > > returned from wait3(&status) [line 457] is assigned to it. > > Or somewhere or other it's going through a cast to unsigned short, but > that doesn't seem all that likely in the signal code, particularly POSIX > style on a 32- or 64-bit architecture. > > If it's Solaris *and* Linux it seems unlikely the status itself is > doing anything funny, though, and that's passed back as int *... So my colleague did some digging and found that the process is marked with WCONTFLG, and that once that happens, you have to check WIFCONTINUED() before anything else, because WCONTFLG overwrites all the bits. He found that the following patch worked for him: --- a/Src/signals.c 2015-09-04 13:38:13.000000000 -0700 +++ b/Src/signals.c 2017-02-16 11:37:26.714503575 -0800 @@ -510,6 +510,11 @@ struct timezone dummy_tz; gettimeofday(&pn->endtime, &dummy_tz); pn->status = status; +#ifdef WIFCONTINUED + if (WIFCONTINUED(status)) + pn->status = SP_RUNNING; +#endif + pn->ti = ru; #else update_process(pn, status); though it occurred to me that it might be better placed in the loop in printjob(), which already has an override for pn->status. Thanks, Danek