|
From: Tom H. <th...@cy...> - 2004-02-28 03:15:40
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-02-28 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 126 tests, 17 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/writev (stderr) |
|
From: Tom H. <th...@cy...> - 2004-02-28 17:02:37
Attachments:
valgrind-race-patch
|
In message <E1A...@gi...>
Tom Hughes <th...@cy...> wrote:
> == 126 tests, 17 stderr failures, 0 stdout failures =================
> corecheck/tests/fdleak_cmsg (stderr)
> corecheck/tests/fdleak_creat (stderr)
> corecheck/tests/fdleak_dup (stderr)
> corecheck/tests/fdleak_dup2 (stderr)
> corecheck/tests/fdleak_fcntl (stderr)
> corecheck/tests/fdleak_ipv4 (stderr)
> corecheck/tests/fdleak_open (stderr)
> corecheck/tests/fdleak_pipe (stderr)
> corecheck/tests/fdleak_socketpair (stderr)
> helgrind/tests/allok (stderr)
> helgrind/tests/deadlock (stderr)
> helgrind/tests/inherit (stderr)
> helgrind/tests/race (stderr)
> helgrind/tests/race2 (stderr)
> helgrind/tests/readshared (stderr)
> memcheck/tests/nanoleak (stderr)
> memcheck/tests/writev (stderr)
A number of these are down to a data races in _dl_lookup_versioned_symbol
which looks like something we already have a suppression for, but in a
slightly different place due to a different glibc version. A patch to
suppress these is attached.
Several others are down to this difference:
***************
*** 7 ****
! by 0x........: do__quit (vg_scheduler.c:...)
--- 7 ----
! by 0x........: ??? (vg_scheduler.c:...)
The one in helgrind/tests/inherit is down to it failing to print
the "XXX We expect an error on inherit.c:48" message but I can't
quite work out where that comes from anyway. To be honest I don't
think I've ever seen that test pass anywhere.
The one in memcheck/tests/nanoleak is because the leak is being
reported as a possible leak, not a definite leak so presumably it
is finding something looks like a pointer into the middle of the
block somewhere.
The last one is down to this, presumably due to a lack of symbols
in the C library on that system:
***************
*** 4 ****
! at 0x........: writev (in /...libc...)
--- 4 ----
! at 0x........: (within /lib/i686/libc-2.3.2.so)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2004-02-28 19:19:59
|
[discussion of regtest failures] I suspect the regtest system would be more robust if we allowed multiple acceptable test results. What I mean is, instead of the required stderr output being in testname.stderr.exp, we also allow testname.stderr.exp1, testname.stderr.exp2, etc, and the test passes if the stderr matches any of these files. Ditto for the .stdout.exp files. This makes it robust against the problem where due to minor glibc differences etc in distros, fixing it on one disto breaks it on others -- which is the root cause I reckon of a lot of the breakage. Comments? J |