Segfault on "task <Tab><Tab>" with zsh 5.0.2

Segfault on "task <Tab><Tab>" with zsh 5.0.2

[Axel Beckert]

[-- Attachment #1: Type: text/plain, Size: 4078 bytes --]

Hi,

I managed to get my zsh 5.0.2 to segfault on entering "task " and then
pressing the tabulator key twice.

/usr/share/zsh/functions/Completion/Unix/_task comes from Debian's
task package (see
http://sources.debian.net/src/task/2.2.0-3/scripts/zsh/_task) and
there is a /usr/share/zsh/functions/Completion/Unix.zwc coming from
Debian's zsh (actually zsh-common) package. As part of the completion
is data output by task, i.e. based on my tasks, it may be necessary to
have one or more of my specfic tasks to reproduce the issue.

Actually with a virgin, i.e. empty task database it is not
reproducible as the completion errors out with
"_task_attributes:zregexparse:4: not enough regex arguments". Also
adding one simple task with "task add foo" does not suffice.

It also is not reproducible with the 5.0.2 zsh from the official
Debian package as currently in Debian Testing/Unstable (5.0.2-3 which
was compiled back in May 2013, probably with gcc 4.7) but it happened
with a 5.0.2 compiled about two weeks ago ([1] likely with gcc 4.8)
without ansi2knr as that one no more seems to exists in Debian
Unstable. (I can lookup the exact compiler versions if necessary.)

[1] http://jenkins.grml.org/view/Debian/job/zsh-binaries/lastSuccessfulBuild/architecture=amd64/
    http://jenkins.grml.org/view/Debian/job/zsh-binaries/lastSuccessfulBuild/architecture=amd64/consoleText

For some reason I expected that both, the earlier and the later
compiled 5.0.2 should both behave identically, but to my surprise only
one of them did segfault and the other seemed to work fine.

So it looks to me as if it depends on either ansi2knr being available
or on the compiler version used. Or maybe some libraries?

It happens with both, my grml-based zshrc as well as with "zsh -f" +
"autoload -Uz compinit" + "compinit"

Compressed (due to its size) backtrace of the following attached:

L1 % zsh -f
L2 % autoload -Uz compinit
L2 % compinit
L2 % task <Tab><Tab>
[1]    19105 segmentation fault (core dumped)  zsh -f
L1 %

First few lines of the backtrace:

Program received signal SIGSEGV, Segmentation fault.
freecvdef (d=0x100000001) at ../../../Src/Zle/computil.c:2799
2799    ../../../Src/Zle/computil.c: No such file or directory.
#0  freecvdef (d=0x100000001) at ../../../Src/Zle/computil.c:2799
#1  0x00007ffff599f8a4 in get_cvdef (args=<optimized out>, nam=<optimized out>) at ../../../Src/Zle/computil.c:2998
#2  bin_compvalues (nam=<optimized out>, args=<optimized out>, ops=<optimized out>, func=<optimized out>) at ../../../Src/Zle/computil.c:3347
#3  0x000000000041c8d6 in execbuiltin (args=args@entry=0x7ffff592c6b0, bn=bn@entry=0x7ffff5ba9520 <bintab+448>) at ../../Src/builtin.c:450
#4  0x000000000042a790 in execcmd (state=0x7ffffffeccf0, input=<optimized out>, output=<optimized out>, how=<optimized out>, last1=2) at ../../Src/exec.c:3259
#5  0x000000000042aced in execpline2 (state=0x7ffffffeccf0, pcode=3, pcode@entry=707, how=18, input=0, output=0, last1=1667588640, last1@entry=0) at ../../Src/exec.c:1677
#6  0x000000000042b214 in execpline (state=state@entry=0x7ffffffeccf0, slcode=<optimized out>, how=how@entry=18, last1=0) at ../../Src/exec.c:1462
#7  0x000000000042c5a2 in execlist (state=state@entry=0x7ffffffeccf0, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0) at ../../Src/exec.c:1245
#8  0x000000000044c1c0 in execif (state=0x7ffffffeccf0, do_exec=0) at ../../Src/loop.c:500
#9  0x0000000000429caf in execcmd (state=0x7ffffffeccf0, input=<optimized out>, output=<optimized out>, how=<optimized out>, last1=2) at ../../Src/exec.c:3200
#10 0x000000000042aced in execpline2 (state=0x7ffffffeccf0, pcode=3, pcode@entry=707, how=18, input=0, output=0, last1=1667588640, last1@entry=0) at ../../Src/exec.c:1677

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

[-- Attachment #2: gdb.txt.xz --]
[-- Type: application/octet-stream, Size: 3516 bytes --]

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2

[Peter Stephenson]

On Fri, 13 Sep 2013 00:18:13 +0200
Axel Beckert <abe@deuxchevaux.org> wrote:
> I managed to get my zsh 5.0.2 to segfault on entering "task " and then
> pressing the tabulator key twice.
> First few lines of the backtrace:
> 
> Program received signal SIGSEGV, Segmentation fault.
> freecvdef (d=0x100000001) at ../../../Src/Zle/computil.c:2799
> 2799    ../../../Src/Zle/computil.c: No such file or directory.
> #0  freecvdef (d=0x100000001) at ../../../Src/Zle/computil.c:2799
> #1  0x00007ffff599f8a4 in get_cvdef (args=<optimized out>, nam=<optimized out>) at ../../../Src/Zle/computil.c:2998
> #2  bin_compvalues (nam=<optimized out>, args=<optimized out>, ops=<optimized out>, func=<optimized out>) at ../../../Src/Zle/computil.c:3347

Looks like a memory error.  Does valgrind give any extra hints?

pws

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2

[Axel Beckert]

Hi Peter,

On Fri, Sep 13, 2013 at 09:37:32AM +0100, Peter Stephenson wrote:
> On Fri, 13 Sep 2013 00:18:13 +0200
> Axel Beckert <abe@deuxchevaux.org> wrote:
> > I managed to get my zsh 5.0.2 to segfault on entering "task " and then
> > pressing the tabulator key twice.
> > First few lines of the backtrace:
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > freecvdef (d=0x100000001) at ../../../Src/Zle/computil.c:2799
> > 2799    ../../../Src/Zle/computil.c: No such file or directory.
> > #0  freecvdef (d=0x100000001) at ../../../Src/Zle/computil.c:2799
> > #1  0x00007ffff599f8a4 in get_cvdef (args=<optimized out>, nam=<optimized out>) at ../../../Src/Zle/computil.c:2998
> > #2  bin_compvalues (nam=<optimized out>, args=<optimized out>, ops=<optimized out>, func=<optimized out>) at ../../../Src/Zle/computil.c:3347
> 
> Looks like a memory error.  Does valgrind give any extra hints?

Not sure if used valgrind properly, but it looks as if it found
something:

% valgrind zsh -f
==6722== Memcheck, a memory error detector
==6722== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==6722== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==6722== Command: zsh -f
==6722== 
==6722== Syscall param capget(data) points to unaddressable byte(s)
==6722==    at 0x584AD77: capget (syscall-template.S:81)
==6722==    by 0x4E34902: cap_init (in /lib/x86_64-linux-gnu/libcap.so.2.22)
==6722==    by 0x4E34995: cap_get_proc (in /lib/x86_64-linux-gnu/libcap.so.2.22)
==6722==    by 0x488184: privasserted (in /bin/zsh5)
==6722==    by 0x46FF92: putpromptchar (in /bin/zsh5)
==6722==    by 0x471178: promptexpand (in /bin/zsh5)
==6722==    by 0x488A21: preprompt (in /bin/zsh5)
==6722==    by 0x43CC97: loop (in /bin/zsh5)
==6722==    by 0x43FD65: zsh_main (in /bin/zsh5)
==6722==    by 0x5783994: (below main) (libc-start.c:260)
==6722==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==6722== 
kiva6% autoload -Uz compinit
kiva6% compinit
==6726== 
==6726== HEAP SUMMARY:
==6726==     in use at exit: 630,408 bytes in 18,315 blocks
==6726==   total heap usage: 24,460 allocs, 6,145 frees, 5,131,211 bytes allocated
==6726== 
==6726== LEAK SUMMARY:
==6726==    definitely lost: 0 bytes in 0 blocks
==6726==    indirectly lost: 0 bytes in 0 blocks
==6726==      possibly lost: 0 bytes in 0 blocks
==6726==    still reachable: 630,408 bytes in 18,315 blocks
==6726==         suppressed: 0 bytes in 0 blocks
==6726== Rerun with --leak-check=full to see details of leaked memory
==6726== 
==6726== For counts of detected and suppressed errors, rerun with: -v
==6726== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 2 from 2)
kiva6% task ==6722== Invalid read of size 8
==6722==    at 0x7FF2E8C: freecvdef (in /usr/lib/x86_64-linux-gnu/zsh/5.0.2/zsh/computil.so)
==6722==    by 0x7FF68A3: bin_compvalues (in /usr/lib/x86_64-linux-gnu/zsh/5.0.2/zsh/computil.so)
==6722==    by 0x41C8D5: execbuiltin (in /bin/zsh5)
==6722==    by 0x42A78F: execcmd (in /bin/zsh5)
==6722==    by 0x42ACEC: execpline2 (in /bin/zsh5)
==6722==    by 0x42B213: execpline (in /bin/zsh5)
==6722==    by 0x42C5A1: execlist (in /bin/zsh5)
==6722==    by 0x44C1BF: execif (in /bin/zsh5)
==6722==    by 0x429CAE: execcmd (in /bin/zsh5)
==6722==    by 0x42ACEC: execpline2 (in /bin/zsh5)
==6722==    by 0x42B213: execpline (in /bin/zsh5)
==6722==    by 0x42C5A1: execlist (in /bin/zsh5)
==6722==  Address 0x100000001 is not stack'd, malloc'd or (recently) free'd
==6722== 
==6722== 
==6722== Process terminating with default action of signal 11 (SIGSEGV)
==6722==  Access not within mapped region at address 0x100000001
==6722==    at 0x7FF2E8C: freecvdef (in /usr/lib/x86_64-linux-gnu/zsh/5.0.2/zsh/computil.so)
==6722==    by 0x7FF68A3: bin_compvalues (in /usr/lib/x86_64-linux-gnu/zsh/5.0.2/zsh/computil.so)
==6722==    by 0x41C8D5: execbuiltin (in /bin/zsh5)
==6722==    by 0x42A78F: execcmd (in /bin/zsh5)
==6722==    by 0x42ACEC: execpline2 (in /bin/zsh5)
==6722==    by 0x42B213: execpline (in /bin/zsh5)
==6722==    by 0x42C5A1: execlist (in /bin/zsh5)
==6722==    by 0x44C1BF: execif (in /bin/zsh5)
==6722==    by 0x429CAE: execcmd (in /bin/zsh5)
==6722==    by 0x42ACEC: execpline2 (in /bin/zsh5)
==6722==    by 0x42B213: execpline (in /bin/zsh5)
==6722==    by 0x42C5A1: execlist (in /bin/zsh5)
==6722==  If you believe this happened as a result of a stack
==6722==  overflow in your program's main thread (unlikely but
==6722==  possible), you can try to increase the size of the
==6722==  main thread stack using the --main-stacksize= flag.
==6722==  The main thread stack size used in this run was 8388608.
==6722== 
==6722== HEAP SUMMARY:
==6722==     in use at exit: 893,406 bytes in 22,714 blocks
==6722==   total heap usage: 233,166 allocs, 210,452 frees, 17,418,357 bytes allocated
==6722== 
==6722== LEAK SUMMARY:
==6722==    definitely lost: 0 bytes in 0 blocks
==6722==    indirectly lost: 0 bytes in 0 blocks
==6722==      possibly lost: 0 bytes in 0 blocks
==6722==    still reachable: 893,406 bytes in 22,714 blocks
==6722==         suppressed: 0 bytes in 0 blocks
==6722== Rerun with --leak-check=full to see details of leaked memory
==6722== 
==6722== For counts of detected and suppressed errors, rerun with: -v
==6722== ERROR SUMMARY: 8 errors from 2 contexts (suppressed: 2 from 2)
[1]    6722 segmentation fault (core dumped)  valgrind zsh -f
valgrind zsh -f  14.68s user 1.45s system 26% cpu 1:01.61 total

HTH.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2

[Peter Stephenson]

On Fri, 13 Sep 2013 13:34:12 +0200
Axel Beckert <abe@deuxchevaux.org> wrote:
> Not sure if used valgrind properly, but it looks as if it found
> something:
> 
> ==6722== Syscall param capget(data) points to unaddressable byte(s)
> ==6722==    at 0x584AD77: capget (syscall-template.S:81)
> ==6722==    by 0x4E34902: cap_init (in /lib/x86_64-linux-gnu/libcap.so.2.22)
> ==6722==    by 0x4E34995: cap_get_proc (in /lib/x86_64-linux-gnu/libcap.so.2.22)

Might not be related, but it's hard to be sure --- if there is bad
memory around, the completion system has a good chance of being the part
that falls over it.  cap_get_proc() is a library call with no arguments,
but it does do allocation --- if you have zsh's own memory allocation
built in there might be some incompatbility.  It's not entirely clear
there's a real problem here, however.

> ==6722==    at 0x7FF2E8C: freecvdef (in /usr/lib/x86_64-linux-gnu/zsh/5.0.2/zsh/computil.so)
> ==6722==    by 0x7FF68A3: bin_compvalues (in /usr/lib/x86_64-linux-gnu/zsh/5.0.2/zsh/computil.so)

That certainly looks like what's causing the crash, though it's
basically the same information as the backtrace.  I was vaguely hoping
valgrind might have some idea if the memory had already been freed, or
something like that.

Thanks for looking.

pws

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2

[Axel Beckert]

Hi Peter,

On Fri, Sep 13, 2013 at 09:37:32AM +0100, Peter Stephenson wrote:
> Looks like a memory error.  Does valgrind give any extra hints?

On Fri, Sep 13, 2013 at 12:51:39PM +0100, Peter Stephenson wrote:
> Might not be related, but it's hard to be sure --- if there is bad
> memory around, the completion system has a good chance of being the part
> that falls over it.

Ah, did you mean malfunctioning RAM as in "hardware defect"?

But shouldn't it be then less easy to reproduce as different memory
areas should be in use when trying it a day later or so?

The machine is a Xen DomU virtual machine btw. -- not sure if that
makes a difference here.

> cap_get_proc() is a library call with no arguments,
> but it does do allocation --- if you have zsh's own memory allocation
> built in there

If ansi2knr or gcc 4.7 vs 4.8 doesn't change anything there, there
should be no difference in compile time options between to 5.0.2
compilation which segfaults and the one which doesn't.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2

[Peter Stephenson]

On Fri, 13 Sep 2013 14:24:26 +0200
Axel Beckert <abe@deuxchevaux.org> wrote:
> On Fri, Sep 13, 2013 at 12:51:39PM +0100, Peter Stephenson wrote:
> > Might not be related, but it's hard to be sure --- if there is bad
> > memory around, the completion system has a good chance of being the part
> > that falls over it.
> 
> Ah, did you mean malfunctioning RAM as in "hardware defect"?

No, I meant e.g. memory that had been freed and then reallocated but was
still being used by something else.

pws

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2

[Pierre Schmitz]

Am 13.09.2013 14:24, schrieb Axel Beckert:
> Hi Peter,
> 
> On Fri, Sep 13, 2013 at 09:37:32AM +0100, Peter Stephenson wrote:
>> Looks like a memory error.  Does valgrind give any extra hints?
> 
> On Fri, Sep 13, 2013 at 12:51:39PM +0100, Peter Stephenson wrote:
>> Might not be related, but it's hard to be sure --- if there is bad
>> memory around, the completion system has a good chance of being the part
>> that falls over it.
> 
> Ah, did you mean malfunctioning RAM as in "hardware defect"?
> 
> But shouldn't it be then less easy to reproduce as different memory
> areas should be in use when trying it a day later or so?
> 
> The machine is a Xen DomU virtual machine btw. -- not sure if that
> makes a difference here.

Seems like some people have a similar or the same problem though:
https://bugs.archlinux.org/task/35736

-- 
Pierre Schmitz, https://pierre-schmitz.com

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2

[Ivan S. Freitas]

On Fri, Sep 13, 2013 at 4:33 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
> Seems like some people have a similar or the same problem though:
> https://bugs.archlinux.org/task/35736

Also reported here:
http://taskwarrior.org/issues/1352

-- 
Ivan Sichmann Freitas
GNU/Linux user #509059
SDF MetaArpa Member http://isf.sdf.org/about.html

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2

[Axel Beckert]

Hi,

On Mon, Sep 16, 2013 at 01:17:08PM -0300, Ivan S. Freitas wrote:
> On Fri, Sep 13, 2013 at 4:33 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
> > Seems like some people have a similar or the same problem though:
> > https://bugs.archlinux.org/task/35736
> 
> Also reported here:
> http://taskwarrior.org/issues/1352

Thanks. This points to two more reports:

https://github.com/robbyrussell/oh-my-zsh/issues/2044
https://bbs.archlinux.org/viewtopic.php?pid=1306993

(And it's definitely not an oh-my-zsh issue.)

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2

[Peter Stephenson]

On Mon, 16 Sep 2013 19:18:42 +0200
Axel Beckert <abe@deuxchevaux.org> wrote:
> On Mon, Sep 16, 2013 at 01:17:08PM -0300, Ivan S. Freitas wrote:
> > On Fri, Sep 13, 2013 at 4:33 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
> > > Seems like some people have a similar or the same problem though:
> > > https://bugs.archlinux.org/task/35736
> > 
> > Also reported here:
> > http://taskwarrior.org/issues/1352
> 
> Thanks. This points to two more reports:
> 
> https://github.com/robbyrussell/oh-my-zsh/issues/2044
> https://bbs.archlinux.org/viewtopic.php?pid=1306993
> 
> (And it's definitely not an oh-my-zsh issue.)

It's not worth sending these unless they actually provide a way of
making the crash easily reproducible, in which case please repost that
information here.

It might produce some sort of hint using "^X?" instead of the second
tab.

pws

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2 (minimal dataset to reproduce the issue found)

[Axel Beckert]

Hi,

On Tue, Sep 17, 2013 at 09:56:57AM +0100, Peter Stephenson wrote:
> It's not worth sending these unless they actually provide a way of
> making the crash easily reproducible, in which case please repost that
> information here.

Granted.

I tried to get a reproducible data set and it took me a while to find
that TaskWarrior feature which causes the segfault: Annotations!

Here's how to reproduce the segfault:

abe@kiva6 % zsh -f
kiva6% autoload -Uz compinit
kiva6% compinit
kiva6% task
A configuration file could not be found in 

Would you like a sample /home/abe/.taskrc created, so taskwarrior can proceed? (yes/no) yes
[task next]
No matches.
kiva6% task add foo
Created task 1.
kiva6% task 1 annotate bar
Annotating task 1 'foo'.
Annotated 1 task.
kiva6% task [1]    4340 segmentation fault (core dumped)  zsh -f
abe@kiva6 % 

I built a tiny tar ball containing the resulting data files (and
generated config file), so to reproduce the issue, it should be
sufficient to have the following:

* The attached task-tab-completion-segfaults-zsh.tgz extracted into
  $HOME:

  drwxr-xr-x abe/tar           0 2013-09-17 17:18 .task/
  -rw-r--r-- abe/tar         402 2013-09-17 17:18 .task/undo.data
  -rw-r--r-- abe/tar         150 2013-09-17 17:18 .task/pending.data
  -rw-r--r-- abe/tar           0 2013-09-17 17:18 .task/completed.data
  -rw-r--r-- abe/tar        1129 2013-09-17 17:18 .taskrc

* A recently compiled zsh 5.0.2 (probably with gcc 4.8).

* TaskWarrior 2.2.0 (e.g. from
  http://taskwarrior.org/projects/taskwarrior/wiki/Download --
  Distribution's package name is often still just "task" which was
  TaskWarrior's old name)

* The _task tab-completion file from the source tar-ball (see
  http://sources.debian.net/src/task/2.2.0-3/scripts/zsh/_task to just
  have a look) at some place where zsh looks for completions.

* Enter "task <Tab><Tab>" into a zsh.

> It might produce some sort of hint using "^X?" instead of the second
> tab.

Nothing, not even a newline or change of the cursor position.

Interestingly the next time, I tried it in the same shell, it
segfaulted on the _first_ Tab key-press.

I used ^U and an empty enter inbetween. At least I could reproduce it
that way multiple times.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2 (minimal dataset to reproduce the issue found)

[Axel Beckert]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Hi again,

On Tue, Sep 17, 2013 at 06:10:59PM +0200, Axel Beckert wrote:
> I built a tiny tar ball containing the resulting data files (and
> generated config file),

Of course I forgot the attachement. Here it is.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

[-- Attachment #2: task-tab-completion-segfaults-zsh.tgz --]
[-- Type: application/x-gtar, Size: 809 bytes --]

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2 (minimal dataset to reproduce the issue found)

[Peter Stephenson]

On Tue, 17 Sep 2013 18:35:10 +0200
Axel Beckert <abe@deuxchevaux.org> wrote:
> On Tue, Sep 17, 2013 at 06:10:59PM +0200, Axel Beckert wrote:
> > I built a tiny tar ball containing the resulting data files (and
> > generated config file),
> 
> Of course I forgot the attachement. Here it is.

Well, completion's very slow, suggesting something fairly heavy is
happening, but it hasn't crashed yet.  I don't suppose it's memory
exhaustion?  The shell's not very robust about that.

pws

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2 (minimal dataset to reproduce the issue found)

[Axel Beckert]

Hi Peter,

On Tue, Sep 17, 2013 at 08:05:46PM +0100, Peter Stephenson wrote:
> > On Tue, Sep 17, 2013 at 06:10:59PM +0200, Axel Beckert wrote:
> > > I built a tiny tar ball containing the resulting data files (and
> > > generated config file),
> 
> Well, completion's very slow, suggesting something fairly heavy is
> happening,

The tool is parsing it's (text-file based) DB of tasks and the
completion can complete to subcommands as well as to each task.

> but it hasn't crashed yet.

Hrm. I really wonder what makes the difference which causes the crash
in more recently compiled zshs on Debian Unstable and ArchLinux
compared to zshs compiled several months ago on these platforms which
don't crash...

> I don't suppose it's memory exhaustion?

I'm very sure that it wasn't an out-of-memory condition.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2 (minimal dataset to reproduce the issue found)

[Bart Schaefer]

On Sep 17,  8:05pm, Peter Stephenson wrote:
}
} Well, completion's very slow, suggesting something fairly heavy is
} happening, but it hasn't crashed yet.  I don't suppose it's memory
} exhaustion?  The shell's not very robust about that.

The stack trace from the very first message in the thread indicates
it dies dereferencing the descr field of a Cvdef structure from the
cvdef_cache array.  The trace doesn't show the call to zsfree so it
is the Cvdef pointer itself that is bad, not the struct contents.

The valgrind output confirms this, which seems to indicate that the
cvdef_cache array is being scribbled on ... but that's static memory,
so it would have to be from overflowing some adjacent static storage
(?) and 0x100000001 looks suspicious as a value that's repeatably so
scribbled.

A watchpoint on cvdef_cache[0] might shed some light.

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2 [PATCH]

[Axel Beckert]

Hi,

TL;DR: Below is a patch which fixes the issue for me. Read the whole
mail for the reasoning.

On Tue, Sep 17, 2013 at 08:05:51PM -0700, Bart Schaefer wrote:
> The stack trace from the very first message in the thread indicates
> it dies dereferencing the descr field of a Cvdef structure from the
> cvdef_cache array.  The trace doesn't show the call to zsfree so it
> is the Cvdef pointer itself that is bad, not the struct contents.
> 
> The valgrind output confirms this, which seems to indicate that the
> cvdef_cache array is being scribbled on ... but that's static memory,
> so it would have to be from overflowing some adjacent static storage
> (?) and 0x100000001 looks suspicious as a value that's repeatably so
> scribbled.
> 
> A watchpoint on cvdef_cache[0] might shed some light.

Thanks for that hint. Helped me to get to the right point:

(gdb) break Src/Zle/computil.c:4920
No source file named Src/Zle/computil.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (Src/Zle/computil.c:4920) pending.
(gdb) watch cvdef_cache[0]
No symbol "cvdef_cache" in current context.
(gdb) r
Starting program: /bin/zsh5 -f
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
kiva6% autoload -Uz compinit
kiva6% compinit
kiva6% task 
Breakpoint 1, setup_ (m=0x6d6280) at ../../../Src/Zle/computil.c:4924
4924    ../../../Src/Zle/computil.c: No such file or directory.
(gdb) watch cvdef_cache[0]
Hardware watchpoint 2: cvdef_cache[0]
(gdb) c
Continuing.
Hardware watchpoint 2: cvdef_cache[0]

Old value = (Cvdef) 0x0
New value = (Cvdef) 0x8104c0
bin_compvalues (nam=<optimized out>, args=<optimized out>, ops=<optimized out>, func=<optimized out>) at ../../../Src/Zle/computil.c:3348
3348    in ../../../Src/Zle/computil.c
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
freecvdef (d=0x100000001) at ../../../Src/Zle/computil.c:2799
2799    in ../../../Src/Zle/computil.c

Next try with a breakpoint on freecvdef calls:

(gdb) break Src/Zle/computil.c:2797
No source file named Src/Zle/computil.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (Src/Zle/computil.c:2797) pending.
(gdb) r
Starting program: /bin/zsh5 -f
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
kiva6% autoload -Uz compinit
kiva6% compinit
kiva6% task 
Breakpoint 1, freecvdef (d=0x100000001) at ../../../Src/Zle/computil.c:2799
2799            zsfree(d->descr);
(gdb) print d
$1 = (Cvdef) 0x100000001
(gdb) print cvdef_cache
$7 = {0x8104c0, 0x809be0, 0x7cbc00, 0x7edde0, 0x7d0c50, 0x7ed680, 0x7cfe80, 0x7ed920}
(gdb) explore 0x7ed920
'0x7ed920' is a scalar value of type 'int'.
0x7ed920 = 8313120
(gdb) explore cvdef_cache
'cvdef_cache' is an array of 'Cvdef'.
Enter the index of the element you want to explore in 'cvdef_cache': 0
The value of 'cvdef_cache[0]' is of type 'Cvdef' which is a typedef of type 'struct cvdef *'
'cvdef_cache[0]' is a pointer to a value of type 'struct cvdef'
Continue exploring it as a pointer to a single value [y/n]: y

  The value of '*(cvdef_cache[0])' is a struct/class of type 'struct cvdef' with the following fields:

   descr = <Enter 0 to explore this field of type 'char *'>
  hassep = 1 .. (Value of type 'int')
     sep = 58 ':' .. (Value of type 'char')
  argsep = 61 '=' .. (Value of type 'char')
    next = <Enter 4 to explore this field of type 'Cvdef'>
    vals = <Enter 5 to explore this field of type 'Cvval'>
    defs = <Enter 6 to explore this field of type 'char **'>
   ndefs = 4 .. (Value of type 'int')
   lastt = 1379534378 .. (Value of type 'int')
   words = 0 .. (Value of type 'int')

Enter the field number of choice: 0
'(*(cvdef_cache[0])).descr' is a pointer to a value of type 'char'
Continue exploring it as a pointer to a single value [y/n]: y
'*((*(cvdef_cache[0])).descr)' is a scalar value of type 'char'.
*((*(cvdef_cache[0])).descr) = 116 't'

Press enter to return to parent value: 

Returning to parent value...

The value of '*(cvdef_cache[0])' is a struct/class of type 'struct cvdef' with the following fields:

   descr = <Enter 0 to explore this field of type 'char *'>
  hassep = 1 .. (Value of type 'int')
     sep = 58 ':' .. (Value of type 'char')
  argsep = 61 '=' .. (Value of type 'char')
    next = <Enter 4 to explore this field of type 'Cvdef'>
    vals = <Enter 5 to explore this field of type 'Cvval'>
    defs = <Enter 6 to explore this field of type 'char **'>
   ndefs = 4 .. (Value of type 'int')
   lastt = 1379534378 .. (Value of type 'int')
   words = 0 .. (Value of type 'int')

Enter the field number of choice: 

Returning to parent value...

'cvdef_cache' is an array of 'Cvdef'.
Enter the index of the element you want to explore in 'cvdef_cache': 
(gdb) print (*(cvdef_cache[0])).descr
$8 = 0x6d6550 "task attributes"
(gdb) print (*(cvdef_cache[1])).descr
$9 = 0x7cd110 "task attributes"
(gdb) print (*(cvdef_cache[2])).descr
$10 = 0x7ec3c0 "task attributes"
(gdb) print (*(cvdef_cache[3])).descr
$11 = 0x7d0390 "task attributes"
(gdb) print (*(cvdef_cache[4])).descr
$12 = 0x7cd810 "task attributes"
(gdb) print (*(cvdef_cache[5])).descr
$13 = 0x7b99d0 "task attributes"
(gdb) print (*(cvdef_cache[6])).descr
$14 = 0x7d09e0 "task attributes"
(gdb) print (*(cvdef_cache[7])).descr
$15 = 0x7d2840 "task attributes"
(gdb) print (*(cvdef_cache[8])).descr
Cannot access memory at address 0x100000001
(gdb) print cvdef_cache[8]
$16 = (Cvdef) 0x100000001

.oO( Bingo! That address looks familiar! )

Looking at the code:

Src/Zle/computil.c:929:#define MAX_CACACHE 8
[...]
Src/Zle/computil.c-2982-static Cvdef
Src/Zle/computil.c-2983-get_cvdef(char *nam, char **args)
Src/Zle/computil.c-2984-{
Src/Zle/computil.c-2985-    Cvdef *p, *min, new;
Src/Zle/computil.c-2986-    int i, na = arrlen(args);
Src/Zle/computil.c-2987-
Src/Zle/computil.c-2988-    for (i = MAX_CVCACHE, p = cvdef_cache, min = NULL; *p && i--; p++)
Src/Zle/computil.c-2989-    if (*p && na == (*p)->ndefs && arrcmp(args, (*p)->defs)) {
Src/Zle/computil.c-2990-        (*p)->lastt = time(0);
Src/Zle/computil.c-2991-
Src/Zle/computil.c-2992-        return *p;
Src/Zle/computil.c-2993-    } else if (!min || !*p || (*p)->lastt < (*min)->lastt)
Src/Zle/computil.c-2994-        min = p;
Src/Zle/computil.c-2995-    if (i)
Src/Zle/computil.c-2996-    min = p;
Src/Zle/computil.c-2997-    if ((new = parse_cvdef(nam, args))) {
Src/Zle/computil.c:2998:    freecvdef(*min);
Src/Zle/computil.c-2999-    *min = new;
Src/Zle/computil.c-3000-    }
Src/Zle/computil.c-3001-    return new;
Src/Zle/computil.c-3002-}

This looks to me as if there's somewehre an off-by-one error which
allows *min to become cvdef_cache[MAX_CVCACHE] aka cvdef_cache[8].

Let's iterate through that for-loop:

First 7 rounds:

i is decremented 7x to 1;
p is incremented 7x to cvdef_cache[7]

"*p && na == (*p)->ndefs && arrcmp(args, (*p)->defs)" never is true,
otherwise the function would have return *p.

Hence the else part runs:

!min is true because min never has been touched and initialised to
NULL, so min becomes set to p.

8th round: *p is still true, i-- is still true (as i is 1 before). p
becomes cvdef_cache[8].

"*p && na == (*p)->ndefs && arrcmp(args, (*p)->defs)" is still false,
otherwise the function would have return *p.

!min is false (as min is now cvdef_cache[7]).

"!*p" is probably false and "(*p)->lastt < (*min)->lastt" probably
too. (In both cases gdb says "Cannot access memory at address", once
0x10000002d and once 0x100000001.) At least that's what my first tries
to patch this issue at this point showed.

So now i is 0 and *p still true.

9th (!) round starting: *p is still true. i is not more true, hence
the body is no more executed. But i-- still is run and hence i is now
-1.

We are now at line 2995: i is -1 and hence true again.

Hence min gets set to p (which is cvdef_cache[8] and hence bogus) and
hence freecvdef(*min) goes boom.

So my patch (against 5.0.2) is as follows:

Index: zsh/Src/Zle/computil.c
===================================================================
--- zsh.orig/Src/Zle/computil.c 2013-09-18 23:09:08.000000000 +0200
+++ zsh/Src/Zle/computil.c      2013-09-18 23:28:55.000000000 +0200
@@ -2992,7 +2992,7 @@
            return *p;
        } else if (!min || !*p || (*p)->lastt < (*min)->lastt)
            min = p;
-    if (i)
+    if (i > 0)
        min = p;
     if ((new = parse_cvdef(nam, args))) {
        freecvdef(*min);

.oO( So much debugging for those two additional characters... )

HTH.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2 [PATCH]

[Peter Stephenson]

On Wed, 18 Sep 2013 23:50:04 +0200
Axel Beckert <abe@deuxchevaux.org> wrote:
> Below is a patch which fixes the issue for me. Read the whole
> mail for the reasoning.

Thanks for going through that. I've committed the patch.

The way i is decremented and p incremented at different points makes it
very difficult to see what's going on --- I suspect there's an argument
for moving the decrement just for clarity but this fix will do fine.

pws

Re: Segfault on "task <Tab><Tab>" with zsh 5.0.2 [PATCH]

[Bart Schaefer]

On Sep 19,  9:49am, Peter Stephenson wrote:
}
} The way i is decremented and p incremented at different points makes it
} very difficult to see what's going on --- I suspect there's an argument
} for moving the decrement just for clarity but this fix will do fine.

I believe get_cadef is going to have the same bug, it uses the identical
technique for managing its cache.

diff --git a/Src/Zle/computil.c b/Src/Zle/computil.c
index 2c323ee..f8983c3 100644
--- a/Src/Zle/computil.c
+++ b/Src/Zle/computil.c
@@ -1608,7 +1608,7 @@ get_cadef(char *nam, char **args)
 	    return *p;
 	} else if (!min || !*p || (*p)->lastt < (*min)->lastt)
 	    min = p;
-    if (i)
+    if (i > 0)
 	min = p;
     if ((new = parse_cadef(nam, args))) {
 	freecadef(*min);

-- 
Barton E. Schaefer