bryan at kadzban.is-a-geek.net
Sun May 2 13:12:21 PDT 2004
Matthew Burgess wrote:
> I personally think a note needs to go in explaining that one of the
> C++ tests might fail. If anyone has done investigations into exactly
> what causes it (maybe it's platform, hardware, or build-host
> specific?) I'd appreciate your input so we can make the note as
> useful as possible.
Just built gcc 3.3.3 from gcc 3.3.2, and I didn't get a timeout in
filebuf_members.cc (that is the test in question, right?). No stray
processes either. Testsuite results were the same as every time before.
This is an NPTL system, LFS 5 plus Teemu's hint. Using HJL binutils
188.8.131.52.7, and glibc 20040103. Built on kernel 2.6.5-rc1, glibc was
built against headers from kernel 2.6.1-rc1. Userspace headers are
Looking at the source for that test, my *guess* would be that the
timeouts are due to some issue with pipes. Of the seven tests in that
file, three have to do with pipes, and the other four are testing normal
Test 1 just opens, then closes, a few different files. AFAICT there
isn't much room for a timeout there.
There are comments before test 2 saying that its purpose is to verify
that filebuf::close() doesn't close a file that the filebuf didn't open
(one of the filebuf constructors takes a FILE * (C stream) argument that
it uses as its stream; it should not close that C stream when it's
destroyed). Again, normal files, not much room for a timeout.
Test 3 just ensures that using the open() syscall, then the fdopen() C
library function, then the filebuf constructor referenced earlier,
results in the same underlying OS file handle.
Test 4 is the first pipe one. It creates a pipe, forks, then in the
child, opens the pipe, sleeps for one second, and exits (which closes
the pipe). In the parent, the test opens the pipe, sleeps for 2 seconds
(so the pipe should be closed), and tries to write a character to it.
The process *should* be getting a SIGPIPE at that point, since the other
end is disconnected. SIGPIPE's handler is set to SIG_IGN earlier in the
function, though, so the signal is ignored. The parent should keep
running unless the kernel's pipe-read function blocks when it shouldn't.
The test then makes sure that closing the filebuf fails (not sure why
it would though).
Test 5 has nothing to do with pipes. It just opens a scratch file (in
std::ios::out mode), then closes it, then opens it (in std::ios::in
mode). Then it verifies that the second open was successful (the file
exists). No chance for a block there, I don't think.
Test 6 makes a pipe, forks, has the child call sgetc() on the filebuf
(which I assume reads from the pipe?), which will block (I think). The
parent tries to open a filebuf on the pipe in I/O plus std::ios::ate
mode, which should fail since pipes can't seek. Now if the child never
wakes up from its sgetc, that might cause the timeout and the extra
process at the end... once the parent closes the pipe though, the child
should get a SIGPIPE and (again) ignore it. The read syscall should
return at that point too.
Test 7 makes a pipe, then forks and has the child open the pipe (for
input), call sleep(2), and close the pipe. The parent sleep(1)'s, opens
the pipe, ensures it's valid, then sleep(3)'s, writes a character to it
and closes. The close should succeed, according to the expectation of
the testsuite. If the problem isn't that the test blocks forever, then
the problem might be this test -- maybe its four-second sleep is too
long for the Expect timeout.
Anybody know what the Expect timeout is?
More information about the lfs-dev