From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6187 invoked by alias); 27 Oct 2014 00:40:48 -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: 33547 Received: (qmail 6272 invoked from network); 27 Oct 2014 00:40:46 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=FrayJNvv c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=DwLLTsr7fuSqbD2rhYcA:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141026174040.ZM7975@torch.brasslantern.com> Date: Sun, 26 Oct 2014 17:40:40 -0700 In-reply-to: <20141014093458.GN5405@sym.noone.org> Comments: In reply to Axel Beckert "Re: Drat, Test/A05 still hanging sometimes" (Oct 14, 11:34am) References: <141006134255.ZM22326@torch.brasslantern.com> <20141007150735.264a09fe@pwslap01u.europe.root.pri> <20141009075200.GV5405@sym.noone.org> <141012114739.ZM23982@torch.brasslantern.com> <20141013030313.GB5405@sym.noone.org> <141013101803.ZM5769@torch.brasslantern.com> <20141014093458.GN5405@sym.noone.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Drat, Test/A05 still hanging sometimes MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 14, 11:34am, Axel Beckert wrote: } } One build failure so far (four slower/busier architectures still } outstanding), but it happened on the architecture where it happened } the most often so far (kfreebsd-amd64). It was inside A05, but not at } the above location but at the test starting at line 179 At that point there should be exactly one child process (the sleep that is being killed), so there shouldn't be any confusion between waiting for a foreground job and waiting for that background job. So it must somehow be the case that the SIGCHLD has been received (post-kill) but the jobtab state of the sleep process did not get properly updated; and now zsh is in an infinite (but not busy, as it stops each pass in sigsuspend()) loop looking for a new SIGCHLD followed by a state change of that process, which is never going to happen. I'll be curious to see if the patch from 33531 changes this at all.