From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26653 invoked by alias); 29 Sep 2016 17:07:32 -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: 39504 Received: (qmail 5058 invoked from network); 29 Sep 2016 17:07:32 -0000 X-Qmail-Scanner-Diagnostics: from mail-pa0-f52.google.com 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(209.85.220.52):SA:0(0.0/5.0):. Processed in 0.575437 secs); 29 Sep 2016 17:07:32 -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=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=1k1MzfbPM4zV4f3DgBaD98IyPJfDapzkYiooTINAbGE=; b=WBO2U58WggSBsBuZLZbTYgrvcaMB740h2eQEDnQ1ZFRtosbLJNbq6yo+Bv7pgCuYog vtXHwshQ+R8p2MBF6xqS/3cNkS/P+ls71L5q5T9S8dbD2ryDWd9ymuhslfaugD0anQcg F7YrxgzlZOjLwmNrVHw6TWpw0QZCO4fbJwC3a/umyIUj66Y1vQEYWnm/8sSRRaqG//oE YbTgGrxd4cnaD2HSVeCEhF1+P6zNnx6zYBMF+KuZE56cM38IMWEn2GllLcqkpzXhefrm Ewmn5z00snuWpJtwlJES8xjcQ0yD5T/uxS4vw9Mzu8KQKDQvH/XSARMJXjV/xLAnxaBE l+EA== 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; bh=1k1MzfbPM4zV4f3DgBaD98IyPJfDapzkYiooTINAbGE=; b=LUBZIyk5HE2Bkvxa0IGNHeNO9v+TpdkzjKirxI9Dcn+ktPmaYEnptaotWdwlYRPssy rxphlS2xJUbCz3LGh99BKVSw4oY6ojI3sfxiAosn3RJL9Wf65TltWS4/8Gy3nkN0BYNH Vu1IhjJfrTTnWnRW/LJcoJEJQlw15o3HYUGtQAdQoadUX487SIuJHBBiL9NxHU2DY3qH 1JYMYNqKVFQK+GP+sqHktX6z35h942Rb8xi2hdZqJ9JQ1ePFED9uPc5ZWfFQe7krJUws w5iXSzHsFjtmTSX/BlsB5chcMLTQuYOG+8C2Eg7W6ajFXA/VyuIzGaw1qqyAM9Paeoy8 Lnzg== X-Gm-Message-State: AA6/9RlkGUjqy4QiNZYnbZpvH9r0yA2pOpfUa2q1++mZcm4EAsvEOfDX1dtFzTLdh2Qrjg== X-Received: by 10.66.26.49 with SMTP id i17mr4067075pag.145.1475168847722; Thu, 29 Sep 2016 10:07:27 -0700 (PDT) From: Bart Schaefer Message-Id: <160929100743.ZM29767@torch.brasslantern.com> Date: Thu, 29 Sep 2016 10:07:43 -0700 In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Re: Where to start debugging zle recursive-edit? / Ctrl-C" (Sep 29, 11:30am) References: <160924133140.ZM29034@torch.brasslantern.com> <160927090957.ZM12910@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh hackers list Subject: Re: Where to start debugging zle recursive-edit? / Ctrl-C MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 29, 11:30am, Sebastian Gniazdowski wrote: } Subject: Re: Where to start debugging zle recursive-edit? / Ctrl-C } } I've got a suspicious effect, after smoothly running no-opt binary for } few days - couldn't recall if I spotted anything suspicious. The } effect is message at shell startup: } } TRAPALRM: scalar parameter abcdef created globally in function TRAPALRM" } } [...] } } and only "setopt localoptions warncreateglobal" from z-sy-h was } reported. Zshrc has at the end: } } TRAPALRM() { abcdef=$(( abcdef + 1 )); } } TMOUT=1 So what's happening is that z-sy-h begins executing, and then *while* it is executing, the first TMOUT occurs and TRAPALRM executes. It therefore picks up the warncreateglobal from the z-sy-h context and so you get the warning about the assignment to abcdef. This could happen any time that z-sy-h is active simultaneously with the TMOUT alarm. } Crash related to Ctrl-C appeared in uncanny situations } AFAIR like Ctrl-R, Ctrl-C multiple times, then menu search completion } with also Ctrl-C, something like this, hard to reproduce. Memory management for menu selection is known to be somewhat fragile; other crashes have occurred there. Usually this seems to happen when tracking of where things should be drawn on the screen gets out of sync with the data structures describing what to draw, see for example workers/37961 (commit f07a1bd0). It would not surprise me to find that an ill-timed interrupt could result in the same sort of problem. There are some queue_signals() regions in complist.c but they're very narrowly defined.