|
From: Duncan S. <bal...@fr...> - 2007-01-02 10:52:18
|
Hi Bart, > A new drd version is available at > http://home.euphonynet.be/bvassche/valgrind/valgrind-6458-drd-2006-12-30.patch.gz. thanks for doing this. I gave it a whirl and it seems to work fine. However it reported a false positive: two threads, thread 1 and thread 2, write to the same memory location in an unsynchronized way, but they write *the same value* to it. Thread 1 then reads the value, which may have last been written by thread 1 or thread 2. This gets reported as a race, even though there is no race since the value read is independent of the order in which the threads wrote it: ==5219== Conflicting load by thread 1 at 0x04413398 size 4 ==5219== at 0x8075A40: system__task_primitives__operations__set_priority (s-taprop.adb:627) <= reads the value ==5219== by 0x8075C8B: system__task_primitives__operations__create_task (s-taprop.adb:787) <= wrote the value ==5219== by 0x80EA0BB: system__tasking__stages__activate_tasks (s-tassta.adb:344) ==5219== by 0x82287DF: notification_support__dispatch___elabb (notification_support-dispatch.adb:5) ==5219== by 0x804C256: adainit (b~smkr.adb:825) ==5219== by 0x804D4A2: main (b~smkr.adb:1619) ==5219== Allocation context: heap, offset 64 in block at 0x4413358 of size 1888 ==5219== at 0x4020516: malloc (vg_replace_malloc.c:207) ==5219== by 0x8073D5F: __gnat_malloc (s-memory.adb:92) ==5219== by 0x8075AF3: system__task_primitives__operations__new_atcb (s-taprop.adb:672) ==5219== by 0x80EA46E: system__tasking__stages__create_task (s-tassta.adb:563) ==5219== by 0x82275EB: notification_support__dispatch__message_taskTKVIP (notification_support-dispatch.adb:55) ==5219== by 0x82287CC: notification_support__dispatch___elabb (notification_support-dispatch.adb:73) ==5219== by 0x804C256: adainit (b~smkr.adb:825) ==5219== by 0x804D4A2: main (b~smkr.adb:1619) ==5219== Other segment start (thread 2) ==5219== at 0x433D3D8: clone (in /lib/tls/i686/cmov/libc-2.5.so) <= writes the value ==5219== Other segment end (thread 2) ==5219== at 0x40007F2: (within /lib/ld-2.5.so) ==5219== by 0x4022720: pthread_mutex_lock (drd_preloaded.c:284) ==5219== by 0x8075511: system__task_primitives__operations__write_lock__2 (s-taprop.adb:333) ==5219== by 0x80753DE: system__task_primitives__operations__lock_rts (s-taprop.adb:209) ==5219== by 0x8075A7C: system__task_primitives__operations__enter_task (s-taprop.adb:653) ==5219== by 0x80EAD08: system__tasking__stages__task_wrapper (s-tassta.adb:1006) ==5219== by 0x402214F: vg_thread_wrapper (drd_preloaded.c:133) ==5219== by 0x425131A: start_thread (in /lib/tls/i686/cmov/libpthread-2.5.so) ==5219== by 0x433D3ED: clone (in /lib/tls/i686/cmov/libc-2.5.so) The context is this: the value in question is the pthread_t thread id of the newly created thread. Both the parent and child need it. The parent gets the value from pthread_create, the child gets it from pthread_self. Once obtained, each of them writes it to a data structure shared between them, memory location 0x04413398 in the above example. After storing the thread id, parent and child call various functions that use it, reading the thread id from the shared data structure; for example system__task_primitives__operations__set_priority reads it (the read reported above). Any thoughts on this? Thanks again and best wishes, Duncan. |