From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5436 invoked from network); 22 May 2001 16:17:25 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 22 May 2001 16:17:25 -0000 Received: (qmail 22720 invoked by alias); 22 May 2001 16:17:09 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 3898 Received: (qmail 22677 invoked from network); 22 May 2001 16:17:07 -0000 From: "Bart Schaefer" Message-Id: <1010522161610.ZM22484@candle.brasslantern.com> Date: Tue, 22 May 2001 16:16:10 +0000 In-Reply-To: <20010522114218.A12553@oobleck.gatech.edu> Comments: In reply to Jason Price "Re: 4.0.1-pre-5 (solaris issues)" (May 22, 11:42am) References: <20010522111111.A11800@oobleck.gatech.edu> <1010522152929.ZM22161@candle.brasslantern.com> <20010522114218.A12553@oobleck.gatech.edu> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-users@sunsite.dk Subject: Re: 4.0.1-pre-5 (solaris issues) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii (Please follow up to zsh-workers.) On May 22, 11:42am, Jason Price wrote: } } > } Was testing: read multio with globbing } > This is a race condition; the "read multio" test depends on a background } > job from the "setup multio" test. } } Is there something I can help test to track this one down? There's nothing to track down. It's a known problem. When you use a multio like `print All files >*' as is done in the "setup multio" test, there is an implicit background job started to write to each of the files, and the stdout of the command is really a pipe to that job. The files do not have any contents until that job flushes its buffers, so when the next test immediately attempts to read from the files, it finds nothing. It might suffice to stick "sleep 1" at the beginning of the "read multio" test. } > Please run "ZTST_verbose=2 make check TESTNUM=V01" so we can see where } > this is happening. } } I have attached the 3 outputs from solaris 2.6, 2.7 and 2.8. Only 2.8 shows a crash when verbose is set. Probaby that means there is a wild pointer somewhere. However, this ... Running test: Unload the modules loaded by this test suite ZTST_test: expecting status: 0 ZTST_execchunk: status 0 Segmentation Fault ... does not agree with ... On May 22, 4:44pm, Oliver Kiddle wrote: } } It is the very last zmodload in the loop which does zmodload -i for } every module it found in config.modules (the `for m in $mods' loop). } I've gone through typing the zmodload commands manually and it is always } the last one which causes the segfault regardless of the order in which } they are loaded. That's rather baffling. What happens if you try leaving various ones out? -- 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