From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7800 invoked from network); 6 Apr 2000 08:18:26 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Apr 2000 08:18:26 -0000 Received: (qmail 15324 invoked by alias); 6 Apr 2000 08:18:15 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10529 Received: (qmail 15315 invoked from network); 6 Apr 2000 08:18:14 -0000 Date: Thu, 6 Apr 2000 10:18:09 +0200 (MET DST) Message-Id: <200004060818.KAA06319@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Wed, 5 Apr 2000 05:09:08 +0000 Subject: Re: FPATH/autoload still strange in -dev-21 Bart Schaefer wrote: > I just got -dev-21 + patches to 10477 compiled and installed, and I'm still > having the strange problems with exported FPATH and (autoload -U) failing > that I described in 10316. I examined strace output and discovered that > in the expression: > > if (autoload -U 2> /dev/null); then > > First zsh forks the subshell, and then the subshell forks again, apparently > in order to redirect the output of the builtin; but then the subshell exits > for some reason I can't follow, leaving the autoload running as an orphan. > So zsh never sees the exit status of autoload. (The process forked from > the subshell is plugging away close()ing each of 256 file descriptors, > except for 0, 1, and 2, most of which are returning EBADF, while its parent > subshell is exiting.) Bart sent me the strace output and there he also repeated the line above, but slightly different: if (autoload -U 2>& /dev/null); then So, Bart, if that is the form you have in .zshenv, this explains the processes. `2>& /dev/null' makes the shell look at the word after the redirection. This isn't a number, so the whole thing is treated like `&>' on file descriptor 2. This makes it treat it as a multio and the funny chap with the many close()s is the zsh-tee process. This is ugly. `&>' on file descriptor 2 makes no sense at all and if even Bart is confused, I think we should do something about it. But what? Make `2>& ' be silently treated like `2> '? Make it emit a warning, or even an error? With the line above, my strace output is exactly the same as for Bart. But I still can't reproduce the bug Bart gets when FPATH is exported. > Now, the odd thing is, the subshell calls _exit(0), so you'd think that zsh > would take the "then" branch of the "if" -- but it doesn't, it takes the > "else" branch. So there must be two race conditions (?) here -- one in the > subshell where it loses track of its child, and another where the topmost > zsh mishandles the exit of that subshell. I'm not sure any more if this is really a race condition. I suspect a memory corruption of some kind, triggered by importing $FPATH from the environment (which would also explain why I can't reproduce, with different allocation behaviours and all that). And the initial setup of fpath also depends on the site-function dirs that are automatically added and so on... Hm, I would try to debug the fpath initialisation in setupvals() and createparamtable(). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de