From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 611 invoked by alias); 5 Aug 2015 20:20:23 -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: 35997 Received: (qmail 988 invoked from network); 5 Aug 2015 20:20:21 -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=A5H3R0+Ird6sxcNhDGvgvjr8k2c2UVmPtrNCfgaeXGU=; b=WRfdatReFmjtPxJBXuRC9rXjMJYwxXdKKT09IcUUwTXZgWfqHZPEqwyrLu4kGoq458 lVjB9pbT25NyJnmyQT/OyHoTUMhV5csE7G1eqqa2Ow3yYIn5h6oNy0maYYkU9pPMsrr0 wvvAUsL9TcL2PWie1H7yTGIw/OHOeU82lSyPzTT7h6QNZ8gMJ4rEEaPEVbyFWnr5OMwu Rbki/wJrfrRW3fX54JJpLwh693RuKttrWNEAIMsvJfDkvgIQyRtEiMhJmgC5VEWa3Zw2 Gtk8mDO9dKJ2+sFek5XBTXy8bh/e2cowriL0h0JudWw3M1OQ2icIp5e5rev8JbDzF+O6 CKEA== X-Gm-Message-State: ALoCoQn8XMZWpigEY/r3CpOW0dMA98M17uwhO1qXK614JFq4nmKSJxUu72LcDKUIkoptQ4W93Q16 X-Received: by 10.60.94.51 with SMTP id cz19mr9543521oeb.8.1438806017934; Wed, 05 Aug 2015 13:20:17 -0700 (PDT) From: Bart Schaefer Message-Id: <150805132014.ZM7746@torch.brasslantern.com> Date: Wed, 5 Aug 2015 13:20:14 -0700 In-Reply-To: Comments: In reply to Mathias Fredriksson "Re: Deadlock when receiving kill-signal from child process" (Aug 5, 10:11pm) References: <150803085228.ZM24837@torch.brasslantern.com> <150803135818.ZM24977@torch.brasslantern.com> <150804235400.ZM9958@torch.brasslantern.com> <150805085258.ZM17673@torch.brasslantern.com> <150805115249.ZM7158@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Deadlock when receiving kill-signal from child process MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 5, 10:11pm, Mathias Fredriksson wrote: } Subject: Re: Deadlock when receiving kill-signal from child process } } On Wed, Aug 5, 2015 at 9:52 PM, Bart Schaefer wrote: } } } } Hm. I'm a little puzzled by the continued appearance of the "no job } } table entry" warning but this -- } } Is it not explainable by disowning the child process (child &!)? At } least when I only do "child &" the error disappears. That explains the ./deadlock.zsh:... warnings but I didn't think it explained the one that happened in TRAPUSR1. Probably not significant. } #0 0x00007fff8abfe166 in __psynch_mutexwait () } #1 0x00007fff8e4b578a in _pthread_mutex_lock () } #2 0x00007fff82ce5750 in fputc () } #9 } #23 0x00007fff853a9340 in OSAtomicCompareAndSwapPtrBarrier$VARIANT$mp () } #24 0x00007fff8e4b5714 in _pthread_mutex_lock () } #25 0x00007fff82ce43a3 in ferror () Dang. Not sure there's much we can do about that one, that's the stdio library deadlocking internally on a mutex because a signal arrived. It'd be pretty ugly for us to try to wrap every stdio call with signal blocking. } #17 0x00007fff896d9ccf in szone_free_definite_size () } #18 0x00000001050ae85c in init_parse () Yet another one of these. We may have to resort to treating all signals the way we treat WINCH, that is, having them constantly queued except for specific moments when we unqueue them. diff --git a/Src/parse.c b/Src/parse.c index 09567fd..84ebf85 100644 --- a/Src/parse.c +++ b/Src/parse.c @@ -456,6 +456,8 @@ init_parse_status(void) void init_parse(void) { + queue_signals(); + if (ecbuf) zfree(ecbuf, eclen); ecbuf = (Wordcode) zalloc((eclen = EC_INIT_SIZE) * sizeof(wordcode)); @@ -466,6 +468,8 @@ init_parse(void) ecnfunc = 0; init_parse_status(); + + unqueue_signals(); } /* Build eprog. */ -- Barton E. Schaefer