Re: TRAPINT doesn't work reliably

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Sep 28, 2019 at 4:17 AM Dennis Schwartz
<dennis.schwartz@xxxxxxxxxxxxxx> 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.