Zsh Mailing List Archive
Messages sorted by:
Re: 4.0.1-pre-5 (solaris issues)
- X-seq: zsh-users 3898
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: 4.0.1-pre-5 (solaris issues)
- Date: Tue, 22 May 2001 16:16:10 +0000
- In-reply-to: <20010522114218.A12553@xxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <Tc0a88d0153ac729d36@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20010522111111.A11800@xxxxxxxxxxxxxxxxxx> <1010522152929.ZM22161@xxxxxxxxxxxxxxxxxxxxxxx> <20010522114218.A12553@xxxxxxxxxxxxxxxxxx>
(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"
} > 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
... 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
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by: