Re: TRAPINT doesn't work reliably

[Dennis Schwartz <dennis.schwartz@xxxxxxxxxxxxxx>]

On Saturday, September 28, 2019 2:29 PM, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:

> Okay, so we have another angle on this: we could try to bisect antigen,
> either temporally (between 1.3.4-1 in Debian stretch and 2.2.3-2 in
> Debian buster) or spatially (taking the 2.2.3-2 version and deleting
> half of its antigen.zsh file at a time, lather, rinse, repeat).

Hmm, it seems I'm having difficulties to determine the exact conditions
when this bug occurs. The commands

$ rm -Rf ~/.antigen && git checkout v1.3.4 && make

also triggers the bug using /usr/bin/zsh. I also updated my .zshrc to
source the correct `bin/antigen.zsh` and also run `antigen apply`.

> > > Does removing that assignment make a difference?
> >
> > No, the bug triggers for any TRAPINT function I've tried so far.
>
> Have you tried an empty function, «TRAPINT () {}»?
>
> Is there any reason to also try a «trap ':' INT»?

Both do nothing. It seems like TRAPINT needs to contain at least one
command or a return statement.


On Saturday, September 28, 2019 4:00 PM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:

> 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.

Okay, I see why I should avoid doing this. The consequence is that I can
only debug version 5.7.1, either compiled myself (so optionally with
debugging flags set) or using the Debian shipped version.

> 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.

Thanks! That was exactly the command I was looking for. If I return to
my initial setup (i.e., using Debian's shipped zsh and antigen + my
original .zshrc) I get:

$ whence zsh
/usr/bin/zsh
$ touch .zshrc
$ cp .zcompdump zcompdum-pre
$ cp -R .antigen antigen-pre
$ zsh -o sourcetrace
+/etc/zsh/zshenv:1> <sourcetrace>
+/etc/zsh/zshrc:1> <sourcetrace>
+/home/USERNAME/.zshrc:1> <sourcetrace>
+/home/USERNAME/.zcompdump:1> <sourcetrace>
+/usr/share/zsh-antigen/antigen.zsh:1> <sourcetrace>
+/home/USERNAME/.antigen/.zcompdump:1> <sourcetrace>
+/home/USERNAME/.antigen/init.zsh:1> <sourcetrace>
+/home/USERNAME/.antigen/.zcompdump:1> <sourcetrace>
$ ll 2      <---- indicating the correct behavior of TRAPINT

$ exit
$ cp .zcompdump zcompdum-mid
$ cp -R .antigen antigen-mid
$ zsh -o sourcetrace
+/etc/zsh/zshenv:1> <sourcetrace>
+/etc/zsh/zshrc:1> <sourcetrace>
+/home/USERNAME/.zshrc:1> <sourcetrace>
+/home/USERNAME/.zcompdump:1> <sourcetrace>
+/usr/share/zsh-antigen/antigen.zsh:1> <sourcetrace>
+/home/USERNAME/.antigen/init.zsh:1> <sourcetrace>
+/home/USERNAME/.antigen/.zcompdump:1> <sourcetrace>
$ ll
TRAPINT:1: not an identifier: F\M-|N)U
$ exit
$ cp .zcompdump zcompdum-post
$ cp -R .antigen antigen-post
$ sha1sum antigen-{pre,mid,post}/**/*
sha1sum: antigen-pre/bundles: Is a directory
ef142d6575f491caf15f643c90abec9809138eff  antigen-pre/debug.log
dbb5aba046583b7e5bd18ff482022e7eb57db6d1  antigen-pre/init.zsh
6a554ac7275ad58b87a484e9be26961ba7bc3bb6  antigen-pre/init.zsh.zwc
sha1sum: antigen-mid/bundles: Is a directory
ab8687454b49cc6d3c55e5d925596cddcbadc342  antigen-mid/debug.log
7f66a86e7d6d7b6847ccd8df0852db90ea40a5af  antigen-mid/init.zsh
6a554ac7275ad58b87a484e9be26961ba7bc3bb6  antigen-mid/init.zsh.zwc
sha1sum: antigen-post/bundles: Is a directory
ab8687454b49cc6d3c55e5d925596cddcbadc342  antigen-post/debug.log
7f66a86e7d6d7b6847ccd8df0852db90ea40a5af  antigen-post/init.zsh
6a554ac7275ad58b87a484e9be26961ba7bc3bb6  antigen-post/init.zsh.zwc
$ sha1sum zcompdum-{pre,mid,post}
2e658e3f3c3c21bec98fedea8390cffd8fdab15e  zcompdum-pre
2e658e3f3c3c21bec98fedea8390cffd8fdab15e  zcompdum-mid
2e658e3f3c3c21bec98fedea8390cffd8fdab15e  zcompdum-post


The only difference between `debug.log` is that `pre` contains less
entries. For `init.zsh`, the only difference is a timestamp in a
comment. I'm a bit lost by these results.


Using the original setup, I can also reproduce the segfault quite
easily:

$ python3
Python 3.7.3 (default, Apr  3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> open('/home/USERNAME/.zshrc', 'w').write('function fun() { echo "' + 'a' * (1 << 24) + '" }\nsource "/usr/share/zsh-antigen/antigen.zsh"\nantigen apply')
16777300
>>>
$ rm -Rf .antigen; rm .zcompdump
$ zsh -o sourcetrace
+/etc/zsh/zshenv:1> <sourcetrace>
+/etc/zsh/zshrc:1> <sourcetrace>
+/home/USERNAME/.zshrc:1> <sourcetrace>
+/usr/share/zsh-antigen/antigen.zsh:1> <sourcetrace>
+/home/USERNAME/.antigen/init.zsh:1> <sourcetrace>
+/home/USERNAME/.antigen/.zcompdump:1> <sourcetrace>
% exit
$ zsh -o sourcetrace
+/etc/zsh/zshenv:1> <sourcetrace>
+/etc/zsh/zshrc:1> <sourcetrace>
zsh: segmentation fault  zsh -o sourcetrace

Running `cp ~/zshrc-good ~/.zshrc` fixed it again (no need for
`zsh -f`).


I spent several hours on trying to debug this issue again today. This of
course pale into insignificance compared to your time developing zsh
(thanks again!), but I hope you understand that I can only spent some
more time again next weekend. Feel free to ask me to try something to
help debugging though!

Cheers,
Dennis