Re: zsh-3.1.9-dev-6 crashes occassionally

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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

	local TMOUT=0

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
involved.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net