[Valgrind-developers] Fwd: valgrind: r12286 - trunk/drd/tests

[Bart V. A. <bva...@ac...>]

(resending such that this message reaches the mailing list)

On Sun, Dec 11, 2011 at 3:28 PM, Florian Krohm <br...@ac...> wrote:

> I noticed two other failures (ignoring the new std_thread testcase).
>
> Fedora 16: drd/pth_cleanup_handler
>
> @@ -1,6 +1,5 @@
>
>  Cleanup handler has been called.
>  Cleanup handler has been called.
> -Test succeeded.
>
>  ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>

Maybe execution of the test program got delayed and maybe alarm(2) made it
stop too early. Let's see whether r12301 helps.


> Rich Coe's "ultra" build: drd/annotate_smart_pointer
>
> @@ -1,4 +1,16 @@
>
> +Conflicting store by thread x at 0x........ size 8
> +   at 0x........: AnnotateCondVarSignal (unified_annotations.h:?)
> +Allocation context: unknown.
> +
> +Conflicting load by thread x at 0x........ size 8
> +   at 0x........: AnnotateCondVarSignal (unified_annotations.h:?)
> +   by 0x........: U_AnnotateHappensBefore (unified_annotations.h:?)
> +   by 0x........: smart_ptr<counter>::set(counter*, AtomicInt32*)
> (annotate_smart_pointer.cpp:?)
> +   by 0x........: smart_ptr<counter>::operator=(counter*)
> (annotate_smart_pointer.cpp:?)
> +   by 0x........: main (annotate_smart_pointer.cpp:?)
> +Allocation context: unknown.
> +
>  Done.
>
> I looked at builds from previous nights and those testcases compared
> consistently. Do these failures look legitimate to you?
>

It took some time but finally I have been able to reproduce this behavior.
As you can see the address at which the conflict happens is not in any
region allocated via malloc() or mmap(). I've also noticed that the
probability that this occurs increases with the number of test iterations
(argv[2]), which is suspicious. I've already encountered similar issues in
the past caused by the NPTL reusing blocks of memory for different threads
without intervening free() or VG_USERREQ__DRD_CLEAN_MEMORY. I'm afraid it's
time again to delve in the NPTL implementation and to see how such false
positives can be avoided.

$ ./vg-in-place --trace-addr=0x7fefff8a0 --fair-sched=yes --tool=drd
--read-var-info=yes --check-stack-var=yes --show-confl-seg=no
drd/tests/annotate_smart_pointer 50 50
==18170== drd, a thread error detector
==18170== Copyright (C) 2006-2011, and GNU GPL'd, by Bart Van Assche.
==18170== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright
info
==18170== Command: ./annotate_smart_pointer 50 50
==18170==
==18170== start 0x7feffe000 size 12288 (thread 1 / vc [ 1: 1 ])
==18170==    at 0x0: ???
==18170== end   0x7feffdf80 size 7328 (thread 1 / vc [ 1: 1 ])
==18170==    at 0x0: ???
==18170== Conflicting store by thread 1 at 0x7fefff8a0 size 8
==18170==    at 0x400FCE: AnnotateCondVarSignal (unified_annotations.h:32)
==18170== Allocation context: unknown.
==18170==
==18170== Conflicting load by thread 1 at 0x7fefff8a0 size 8
==18170==    at 0x400FDD: AnnotateCondVarSignal (unified_annotations.h:34)
==18170==    by 0x401071: U_AnnotateHappensBefore (unified_annotations.h:46)
==18170==    by 0x4018DD: smart_ptr<counter>::set(counter*, AtomicInt32*)
(annotate_smart_pointer.cpp:239)
==18170==    by 0x401778: smart_ptr<counter>::operator=(counter*)
(annotate_smart_pointer.cpp:208)
==18170==    by 0x401377: main (annotate_smart_pointer.cpp:326)
==18170== Allocation context: unknown.
==18170==
Done.
==18170==
==18170== For counts of detected and suppressed errors, rerun with: -v
==18170== ERROR SUMMARY: 16 errors from 2 contexts (suppressed: 20 from 20)

Bart.