From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26854 invoked from network); 30 Oct 2000 08:32:14 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 Oct 2000 08:32:14 -0000 Received: (qmail 18983 invoked by alias); 30 Oct 2000 08:32:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13096 Received: (qmail 18955 invoked from network); 30 Oct 2000 08:32:04 -0000 Date: Mon, 30 Oct 2000 09:32:00 +0100 (MET) Message-Id: <200010300832.JAA18859@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: =?iso-8859-1?Q?Thomas_K=F6hler?='s message of Sat, 21 Oct 2000 14:34:26 +0200 Subject: Re: zsh-3.1.9-dev-6 crashes occassionally Thomas Koehler wrote: > Hi there, > I have the following problem with zsh-3.1.9-dev-6 on Debian GNU/Linux > for i386: > Sometimes, while trying to complete, zsh crashes and dumps core. In > fact, the problem has been there for quite a while now, perhaps it has > been there since the new completions system has been introduced - I > don't know. The problem is: I can't reproduce the bug. It just happens > to occur every once in a while. > Well, this is not the only problem: Sometimes, zsh forgets its > completion settings. I use this line in my .zshrc: > zstyle ':completion:*' completer _complete _ignored _match _correct _approx= > imate _prefix > Now, sometimes, for some strange reason, zsh forgets to complete on tab > and starts to _correct things right away: For example, I had a directory > "abcdef" and a directory "abx" and typed "cd abc" which resulted in > "cd abx". Thomas sent me his .zshrc, I tried, but couldn't reproduce it. But I think I know where it comes from and why I never could reproduce it (he reported it already quite some time ago, I think; or something similar?). 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. 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...). 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. (This could be a good reason to finally write a function that is called everywhere zsh waits for something. And then we could allow modules to hook into it or something.) Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de