* Re: Reliable zsh-3.0.0 core dump
[not found] <199608251116.NAA00518@hzoli.ppp.cs.elte.hu>
@ 1996-08-25 19:10 ` Bart Schaefer
1996-08-25 23:59 ` Zoltan Hidvegi
0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 1996-08-25 19:10 UTC (permalink / raw)
To: Zoltan Hidvegi; +Cc: zsh-workers
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"
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Reliable zsh-3.0.0 core dump
1996-08-25 19:10 ` Reliable zsh-3.0.0 core dump Bart Schaefer
@ 1996-08-25 23:59 ` Zoltan Hidvegi
1996-08-26 0:50 ` Bart Schaefer
0 siblings, 1 reply; 5+ messages in thread
From: Zoltan Hidvegi @ 1996-08-25 23:59 UTC (permalink / raw)
To: schaefer; +Cc: zsh-workers
> 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 {
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Reliable zsh-3.0.0 core dump
1996-08-25 23:59 ` Zoltan Hidvegi
@ 1996-08-26 0:50 ` Bart Schaefer
1996-08-26 18:36 ` Zoltan Hidvegi
0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 1996-08-26 0:50 UTC (permalink / raw)
To: Zoltan Hidvegi; +Cc: zsh-workers
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"
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Reliable zsh-3.0.0 core dump
1996-08-26 0:50 ` Bart Schaefer
@ 1996-08-26 18:36 ` Zoltan Hidvegi
0 siblings, 0 replies; 5+ messages in thread
From: Zoltan Hidvegi @ 1996-08-26 18:36 UTC (permalink / raw)
To: schaefer; +Cc: zsh-workers
> } 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Reliable zsh-3.0.0 core dump
@ 1996-08-18 20:31 Bart Schaefer
0 siblings, 0 replies; 5+ messages in thread
From: Bart Schaefer @ 1996-08-18 20:31 UTC (permalink / raw)
To: zsh-workers
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"
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1996-08-26 18:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <199608251116.NAA00518@hzoli.ppp.cs.elte.hu>
1996-08-25 19:10 ` Reliable zsh-3.0.0 core dump Bart Schaefer
1996-08-25 23:59 ` Zoltan Hidvegi
1996-08-26 0:50 ` Bart Schaefer
1996-08-26 18:36 ` Zoltan Hidvegi
1996-08-18 20:31 Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).