Re: zsh 5.0.6 hanged in freejob from TRAPCHLD

[Bart Schaefer <schaefer@brasslantern.com>]

On Oct 1, 10:00am, Peter Stephenson wrote:
} Subject: Re: zsh 5.0.6 hanged in freejob from TRAPCHLD
}
} > The stack trace seems to indicate that the problem likely originates in
} > lexrestore() which calls free() directly (without the signal-safe zfree()
} 
} The queue_signals() is presumably important.  I don't see that zfree()
} makes a practical difference here, though

Right, I realized after hitting "send" that zfree() is only signal-safe
when using zsh's mem.c malloc() replacement -- in which case free() is
also a wrapper for zfree() instead of the other way around.

This plus the possibility of interrupting the copy from the saved state
back to the globals is the need for queue_signals() inside lexrestore().

There may be other save/restore routines that still need this treatment,
I haven't yet done an audit.