|
From: Mark W. <mj...@re...> - 2014-09-02 09:29:54
|
On Tue, 2014-09-02 at 10:59 +0200, Mark Wielaard wrote: > Because we are looking at doing a beta/release for 3.10.0 soon I ran the > regtests on various setups to see what the results look like: Forgot I also had one "perfect score" (those are of course boring, but it is good to know that zero fail is possible) and one "near perfect" score. It has one fail I didn't see yesterday. - i386, glibc-2.12, linux-2.6.32 == 621 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == - amd64, glibc-2.17, linux-3.10.0 == 707 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/tc22_exit_w_lock (stderr) That one is also seen on some other setups. Which is probably caused by enabling inlined frames in the backtraces because one of the stacktraces looks like: ==18091== Possible data race during write of size 1 at 0x5C1767F by thread #1 ==18091== Locks held: none ==18091== at 0x4C33ECE: mempcpy (vg_replace_strmem.c:1354) ==18091== by 0x4011DD2: _dl_allocate_tls_init (dl-tls.c:459) ==18091== by 0x4E42311: get_cached_stack (allocatestack.c:252) ==18091== by 0x4E42311: allocate_stack (allocatestack.c:482) ==18091== by 0x4E42311: pthread_create@@GLIBC_2.2.5 (pthread_create.c:451) ==18091== by 0x4C2E6A7: pthread_create_WRK (hg_intercepts.c:270) ==18091== by 0x4C2F5E9: pthread_create@* (hg_intercepts.c:301) ==18091== by 0x4009B2: main (tc22_exit_w_lock.c:42) ==18091== ==18091== This conflicts with a previous write of size 1 by thread #2 ==18091== Locks held: none ==18091== at 0x4E41D62: start_thread (pthread_create.c:242) ==18091== Address 0x5c1767f is not stack'd, malloc'd or on a free list Note the extra get_cached_stack/allocate_stack frame at the same address. I assume some suppression isn't triggering now. Cheers, Mark |