Zsh Mailing List Archive
Messages sorted by:
Re: zsh-3.1.9-dev-6 crashes occassionally
- X-seq: zsh-workers 13100
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: zsh-3.1.9-dev-6 crashes occassionally
- Date: Mon, 30 Oct 2000 16:18:08 +0000
- In-reply-to: <200010300832.JAA18859@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <200010300832.JAA18859@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Oct 30, 9:32am, Sven Wischnowsky wrote:
} Thomas uses a trap handler for the ALRM signal and with TMOUT=1 to
} update his prompt. The trap handler uses several local parameters.
} Since zsh invokes (shell-code) trap handler asynchronously from the
} signal handler, this could easily mess up the parameter table if the
} signal comes at a time when the completion code is playing with the
} parameter table itself.
An easy way to find out -- at the top of _main_complete, add
which will shut off the alarm timer during the completion functions. I
just tested this by setting up a TMOUT=1 refresh of my xterm title bar,
plus a completion function that does nothing but "sleep 5", and indeed
the title bar stopped updating for 5 seconds when I pressed TAB.
Zed does this same thing.
One other item of note: For some strange reason, it's not possible to
alter TRAPxxx functions with "zed -f". They come up in the editor, and
if you create one from scratch it sticks, but no changes that you make
to an already-existing TRAPxxx function are remembered. No matter how
you exit zed, they always revert to their previous value.
} We talked about this several times already. We either need to protect
} parts of the code (blocking signals there) or we should make the
} signal handlers do as little as possible, setting only some flags or
} something like that and call the trap handler shell-code somewhere
} else where it can be called savely. We `decided' to use the second
} solution, I think (and the first one is expensive and we have to find
} all the right places and...).
I don't recall what the decision was, but setting a flag isn't enough
in the case of TMOUT/TRAPALRM -- you also have to force the blocking
read in getkey() to be interrupted and not restarted, or zsh will not
get to "somewhere else" in a timely fashion. That means fooling with
setjmp/longjmp, most likely, which is an entire other can of worms we
might be better off not opening.
} We could also use a mixture: a global flag that tells the signal code
} that it's save to invoke the trap handler right away but normally it
} would only make them be called later. That flag could be set when zsh
} is waiting for an external command, reading somethin or whatever.
That would probably be enough to take care of the blocking-read issue.
However, our choice of "a safe place" to invoke the handler is still
going to have be made with some care -- it has to be a place (or more
than one) that is *guaranteed* to be reached quickly, and I just don't
see how we can possibly enforce that when arbitrary module code may get
Bart Schaefer Brass Lantern Enterprises
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by: