|
From: Tom H. <th...@cy...> - 2004-02-28 17:02:37
|
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/
|