From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 6b143057 for ; Sat, 28 Sep 2019 16:01:53 +0000 (UTC) Received: (qmail 15454 invoked by alias); 28 Sep 2019 16:01:43 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24299 Received: (qmail 2312 invoked by uid 1010); 28 Sep 2019 16:01:43 -0000 X-Qmail-Scanner-Diagnostics: from mail-lj1-f178.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25580. spamassassin: 3.4.2. Clear:RC:0(209.85.208.178):SA:0(-1.9/5.0):. Processed in 4.421007 secs); 28 Sep 2019 16:01:43 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.208.178 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WL34XkKACPeJgTqWV3z4rWwQAiN5Svf/j0juzKUX35c=; b=MrNiITSHhcBmEybbEeOcM6ml2cNjObKK3sviTRtrr871bdY0IJcY6QlFr0+gHZEHuO 3ZO8H1mgqIHljvhiVlVygWcA+9KkBmav+l2sjjuREAzPgNQ7jFWKU4aDNaWGlJjiIW8Q bhC1efcgX1Mlg3GNlA4hMmB73iL0VRsF5rew1jWfsHcTOWOXNkplGYjwyWnCx57qRXL0 Iw6SSBs0UDsDtmCUa7ljFhFED37GsqRO+aZJSu/2GglKbMFMlIjNr+4xVTgpqS0JCDNP aFXlhKf30KDLElMFzI4TFW4cMvKQWGFyPGRpbuve23diX8hQ1VLCb4Ht99q8Ed5rFU4N Tx2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WL34XkKACPeJgTqWV3z4rWwQAiN5Svf/j0juzKUX35c=; b=hbJDld1zoTL87eQNFLblmusHGivuxnslVgjpWPdqmodEQ6aWDdQ2aeg8wCA1BesU1l BbVAqf+CgqNYEGbq11qHEc1u2mDXiBKxvJcPqRhgVfzJcSZRV7fZWumY8lVDVn2i+MMF 6KdqEuvacEeMJlH9VWPb46KbEF2nGo8ksA1l5TUG/NmUOqGpi46XNL+qtO3HrId3yewj zhP+RFVliaaHZjSViF1dY2v8MAXrNsnrTofv+2GAHANsKbD0VIXHSh1bT8ZEZ5xI0rvF 81BL5PIDIR1swri/ifhFYZqeM1/AFvMzbCW9H31TPiyC5h/7OXszbpnwr3NWNxwd/sdc FrOw== X-Gm-Message-State: APjAAAXAHmzE8FKzbSloBzkg7lnGSWesgAP8TBB9qtiQFCcSOq33u4H5 hwKqP76uxrNadBdxZ/XCs6MYemsrKN9ZRYa1CoyHqd0zavU= X-Google-Smtp-Source: APXvYqwQLFK7kr2hpTntT6li41qrbaM+bsHPHB/x1I1TeVGxYDNiqO/HT7BqO0RLG/g5evnOlnJpD3eC0TPKL//J4kU= X-Received: by 2002:a2e:4258:: with SMTP id p85mr6558705lja.172.1569686462921; Sat, 28 Sep 2019 09:01:02 -0700 (PDT) MIME-Version: 1.0 References: <1394985674.3969083.1569420087673@mail2.virginmedia.com> <22AgAhXQWzavJGhNA8tFbGSMGk8z3KDGGa-pICX0lWszH622z2_nnc1acuvW3OcIbqAaXM_WAGJwmQU5Oph83DGbfQEplu1t3o7F5omeC4w=@protonmail.com> <1569434163.10786.26.camel@samsung.com> <1569511539.3770.6.camel@samsung.com> <7P_7qK1o03NLAWi2yO8YMPN4ErtxVF9fCDTtiPNjfRrzqKcmoysqAeR8nQ1B5DEY_uYE_Y6EBGsxysbflCAyLbm_h5qrobU4F0143UCxWW8=@protonmail.com> In-Reply-To: From: Bart Schaefer Date: Sat, 28 Sep 2019 09:00:51 -0700 Message-ID: Subject: Re: TRAPINT doesn't work reliably To: Dennis Schwartz Cc: Daniel Shahaf , Peter Stephenson , "zsh-users@zsh.org" Content-Type: text/plain; charset="UTF-8" On Sat, Sep 28, 2019 at 4:17 AM Dennis Schwartz wrote: > > * On my system (Debian 10), I need to compile zsh with the version > number from my default Debian installation. So I always do > `git checkout zsh-5.7.1 -- Config/version.mk` before I compile. So, you should definitely STOP doing that. It's only creating confusion. The version number from config.mk determines three things: 1. The function load path 2. The compiled module load path 3. The format of "compiled" function definitions from .zwc files and as a corollary to #3, whether zsh will load the .zwc file at all, because it compares a version number embedded in the file to to version number of the compiled zsh. If you compile version X.Y.Z of zsh with the version.mk from version P.D.Q, particularly on a host where P.D.Q was previously (or is currently) installed, you are extremely likely to either be linking with an incompatible shared object file, or loading a .zwc file whose bytecode is garbage to the internals of your newly compiled binary. Either of those things could be causing the crashes you are seeing, or cause valgrind to generate results that have no real relationship to the original problem. This part -- > * `zsh` needs to be started twice. > * The first time the bug cannot be triggered. > * The second time the bug can be triggered by typing a character and > then hitting TAB to autocomplete. Now hit Ctrl+C to interrupt. -- suggests very strongly that this is related to loading an incorrect version of a compiled function as a result of the .zcompdump file having been updated, or some similar automatic configuration update, probably (as you suggest) being performed by antigen. To get anywhere with this, we need a zsh that is compiled entirely consistently, not with bits an pieces of different versions. Either check out the entire git revision matching your OS version, not just the version number file, or run the entire test with the most recent version, including the correct version.mk for that build. I would also suggest that you go back to the configuration where you first observed the problem (i.e., do NOT use a custom-compiled binary) and start zsh with zsh -o sourcetrace which will show you where all the configuration files are being found. You can then compare that to "zsh -o sourcetrace" from your newly compiled binary to determine which files are the same and which are different in the event that the bug behavior changes with the new build. If after correcting the build process you STILL observe that zsh must be started twice, comparing sourcetrace from the first and second runs may also be informative.