From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9108 invoked from network); 6 Apr 2000 10:49:44 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Apr 2000 10:49:44 -0000 Received: (qmail 29102 invoked by alias); 6 Apr 2000 10:49:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10540 Received: (qmail 29093 invoked from network); 6 Apr 2000 10:49:27 -0000 Date: Thu, 6 Apr 2000 12:49:10 +0200 (MET DST) Message-Id: <200004061049.MAA06636@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Thu, 6 Apr 2000 09:51:41 +0000 Subject: Re: FPATH/autoload still strange in -dev-21 Bart Schaefer wrote: > ... > > } 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 memory corruption ... steps on the exit status of the subshell as > returned to the parent, somehow? I can't see how that could be ... the > subshell is calling _exit(0) but the parent still takes the false branch. > Hrm. I was thinking about something that messes up some memory used somewhere when that `if' is executed. Wild guessing, of course, but memory problems are the only ones I can think of when thinking about the difference between FPATH in the environment and not in the environment. I may be completely wrong, of course. Debugging session in execif() could tell us something. > } And the initial setup of fpath also depends on the site-function dirs > } that are automatically added and so on... > > I do NOT compile with --enable-function-subdirs, if that matters. Hm. I have some default function dirs... Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de