Reliable zsh-3.0.0 core dump

Reliable zsh-3.0.0 core dump

[Bart Schaefer]

Install the following function and alias; then execute run-help (via ZLE
with ESC h) more than once.  It works the first time, and dumps core in
parsecomp() the second time (with a trashed stack).

zman() {
    if [[ -f /usr/local/lib/zsh/functions/run-help ]]
    then
	autoload run-help
	FPATH=/usr/local/lib/zsh/functions \run-help $1
    elif [[ -f /usr/local/lib/zsh/help/$1 ]]
    then less /usr/local/lib/zsh/help/$1
    else man $1
    fi
}
alias run-help zman

I found this by accident, because if you change it to be:

zman() {
    if [[ -f /usr/local/lib/zsh/functions/run-help ]]
    then
	autoload run-help
	unalias run-help				# Added this line
	FPATH=/usr/local/lib/zsh/functions \run-help $1
    elif [[ -f /usr/local/lib/zsh/help/$1 ]]
    then less /usr/local/lib/zsh/help/$1
    else man $1
    fi
}

Then it works exactly as desired.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Reliable zsh-3.0.0 core dump

[Zoltan Hidvegi]

> } While testing this I
> } also discovered that pipe synchronization was really necessary.
> 
> Can you say a bit about why (and maybe add a comment to the code!)?

I cannot unfortunately.  I just saw oddly suspended by tty output less
processes at the end of pipes which was caused by this.  I had no time to
investigate it further.  I'm very busy at the moment with some non-zsh work
here (I have to set up several machines this week).

Zoltan

Re: Reliable zsh-3.0.0 core dump

[Bart Schaefer]

On Aug 26,  1:59am, Zoltan Hidvegi wrote:
} Subject: Re: Reliable zsh-3.0.0 core dump
}
} > I can't get a core dump either if I use --enable-zsh-mem ... only with
} > the system malloc.  I hadn't tried zsh-mem before.
} 
} Did you try --enable-zsh-{debug,mem{,-debug},secure-free}?

Yes; they produced no warnings, and of course the core dump didn't
happen even with nothing more than --enable-zsh-mem, so ...

} The patch below fixes a bug which may cause that.

No such luck.  I still get a core dump.

} While testing this I
} also discovered that pipe synchronization was really necessary.

Can you say a bit about why (and maybe add a comment to the code!)?

} > In the second case, the built-in alias of run-help to man expanded before
} > help was invoked; in the first case it did not.  I think it should be
} > consistent (and I think the first case is how it should work, i.e. don't
} > expand the alias, but that's less important).
} > 
} > Or is this intentional and simply not documented?
} 
} It is half-intentional.  When the current word for completion is requested
} from the lexer alias expansion is disabled for that word which is good and
} reasonable.  The same mechanism is used by run-help.

I agree that alias expansion should be disabled for the current word; I
just think it should also be disabled for run-help no matter what word
is "current."  For run-help's purposes only the word in command position
is interesting.


-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: Reliable zsh-3.0.0 core dump

[Zoltan Hidvegi]

> I can't get a core dump either if I use --enable-zsh-mem ... only with
> the system malloc.  I hadn't tried zsh-mem before.

Did you try --enable-zsh-{debug,mem{,-debug},secure-free}?

The patch below fixes a bug which may cause that.  While testing this I
also discovered that pipe synchronization was really necessary.

> BTW, here's a probably-related oddity (vanilla 3.0.0 zsh -f withOUT the
> function above):
> 
> zagzig% set -vx
> zagzig% run-help<ESC h>			<-- cursor imediately after the `p'
> zagzig% run-help run-help
> run-help run-help
> + man run-help
> No manual entry for run-help
> zagzig% run-help <ESC h>		<-- space between `p' and cursor
> zagzig% run-help man
> run-help man
> + man man
> 
> In the second case, the built-in alias of run-help to man expanded before
> help was invoked; in the first case it did not.  I think it should be
> consistent (and I think the first case is how it should work, i.e. don't
> expand the alias, but that's less important).
> 
> Or is this intentional and simply not documented?

It is half-intentional.  When the current word for completion is requested
from the lexer alias expansion is disabled for that word which is good and
reasonable.  The same mechanism is used by run-help.

Zoltan


*** Src/zle_tricky.c	1996/08/23 19:18:43	2.73
--- Src/zle_tricky.c	1996/08/25 23:29:14
***************
*** 3871,3877 ****
--- 3871,3879 ----
      HEAPALLOC {
  	zleparse = 1;
  	lexsave();
+ 	metafy_line();
  	inpush(dupstrspace((char *) line), 0);
+ 	unmetafy_line();
  	strinbeg();
  	pushheap();
  	do {

Re: Reliable zsh-3.0.0 core dump

[Bart Schaefer]

On Aug 25,  1:16pm, Zoltan Hidvegi wrote:
} Subject: Re: Reliable zsh-3.0.0 core dump
}
} > Install the following function and alias; then execute run-help (via ZLE
} > with ESC h) more than once.  It works the first time, and dumps core in
} > parsecomp() the second time (with a trashed stack).
} > 
} > zman() {
} >     if [[ -f /usr/local/lib/zsh/functions/run-help ]]
} >     then
} > 	autoload run-help
} > 	FPATH=/usr/local/lib/zsh/functions \run-help $1
} >     elif [[ -f /usr/local/lib/zsh/help/$1 ]]
} >     then less /usr/local/lib/zsh/help/$1
} >     else man $1
} >     fi
} > }
} > alias run-help zman
}                 ^ here you just missed an `=', didn't you?
} 
} I cannot get a core-dump this way.

I can't get a core dump either if I use --enable-zsh-mem ... only with
the system malloc.  I hadn't tried zsh-mem before.

I also get the core dump if and only if I have done:

zigzag% run-help<ESC h>

That is, if I ask for help on run-help itself.  Furthermore, I get the
crash if and only if there is NO SPACE between the `p' and the cursor
when I hit <ESC h>.

Additional information:  The first time I do this, I get the help *twice*
(that is, it says "Press any key for more help or q to quit" and then
when I press q it shows me the same help again).  The second time I do
it is when I get the core dump, and that second time it doesn't matter
what the word in command position is.

I get the help twice that way even with --enable-zsh-mem; only the crash
is prevented.  --enable-zsh-mem-debug and --enable-zsh-mem-warning don't
produce any warnings at all.

If I run inside GDB, I get this much of a stack trace:

(gdb) where
#0  0x40030f12 in _free_internal ()
#1  0x400a0238 in __DTOR_END__ ()
#2  0x400d23f4 in _fraghead ()
#3  0x806e280 in expl ()
Cannot access memory at address 0x65685498.

This happens even in zsh -f with no HELPDIR defined.

If I run outside GDB and then examine the core file, I get parsecomp() in
frame #0 and the rest of the stack is trashed (but that wasn't with zsh -f,
now that I think about it).

} I use a modified run-help:
} 
} -elif [[ -n "${HELPDIR:-}" && -r $HELPDIR/$1 ]]
} +elif [[ -n "${HELPDIR:-}" && -r $HELPDIR/$1 && $1 != compctl ]]

Heh.  That was one of the reasons I rewrote run-help in the first place.

BTW, here's a probably-related oddity (vanilla 3.0.0 zsh -f withOUT the
function above):

zagzig% set -vx
zagzig% run-help<ESC h>			<-- cursor imediately after the `p'
zagzig% run-help run-help
run-help run-help
+ man run-help
No manual entry for run-help
zagzig% run-help <ESC h>		<-- space between `p' and cursor
zagzig% run-help man
run-help man
+ man man

In the second case, the built-in alias of run-help to man expanded before
help was invoked; in the first case it did not.  I think it should be
consistent (and I think the first case is how it should work, i.e. don't
expand the alias, but that's less important).

Or is this intentional and simply not documented?

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"