Re: Reliable zsh-3.0.0 core dump

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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"