Zsh Mailing List Archive
Messages sorted by:
Re: TRAPINT doesn't work reliably
- X-seq: zsh-users 24299
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Dennis Schwartz <dennis.schwartz@xxxxxxxxxxxxxx>
- Subject: Re: TRAPINT doesn't work reliably
- Date: Sat, 28 Sep 2019 09:00:51 -0700
- Cc: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>, Peter Stephenson <p.stephenson@xxxxxxxxxxx>, "zsh-users@xxxxxxx" <zsh-users@xxxxxxx>
- 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==
- In-reply-to: <ODmJIQmuJJcZdaTGdd_T4zXxU0G7RHNJl3pSGxRC3qTePtsFsXSosieytwRTp2x2GTxggH_l9ZGZQb19rELfq70ZCOU9Xtr0Ik4ks9SpbOQemail@example.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:email@example.com>
- List-unsubscribe: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <CGME20190917164905epcas1p4ad458ffcd504501780d522880c81de3e@epcas1p4.samsung.com> <Bczpjmkq93UC9ogVXedAec4MSWn1xm79AtK56m7J7_XKU3g1oWkhoUeoj9_CjqM_bdhDM3WFcb0IWT04yMJctdhKDGj_fiAyOLAfaMatz5kemail@example.com> <firstname.lastname@example.org> <22AgAhXQWzavJGhNA8tFbGSMGk8z3KDGGa-pICX0lWszH622z2_nnc1acuvW3OcIbqAaXM_WAGJwmQU5Oph83DGbfQEplu1t3o7F5omeC4wemail@example.com> <firstname.lastname@example.org> <EwtKvyologv1mcP4t0gYc4lnyj-ccruEDWJM6kEh3_-H1P6kvlnSEV_LunkUg4AxuDZkdVcoPHq2KnqTqQ4pOAzRd2bXfkj0tjAvgg2-cQQemail@example.com> <firstname.lastname@example.org> <7P_7qK1o03NLAWi2yO8YMPN4ErtxVF9fCDTtiPNjfRrzqKcmoysqAeR8nQ1B5DEY_uYE_Y6EBGsxysbflCAyLbm_h5qrobU4F0143UCxWW8email@example.com> <firstname.lastname@example.org> <ODmJIQmuJJcZdaTGdd_T4zXxU0G7RHNJl3pSGxRC3qTePtsFsXSosieytwRTp2x2GTxggH_l9ZGZQb19rELfq70ZCOU9Xtr0Ik4ks9SpbOQemail@example.com>
On Sat, Sep 28, 2019 at 4:17 AM Dennis Schwartz
> * 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
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.
Messages sorted by: