You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(4) |
2
(17) |
3
(9) |
4
(14) |
5
(10) |
6
(11) |
7
(8) |
|
8
(9) |
9
(11) |
10
(29) |
11
(27) |
12
(29) |
13
(36) |
14
(8) |
|
15
(18) |
16
(30) |
17
(25) |
18
(6) |
19
(16) |
20
(13) |
21
(10) |
|
22
(16) |
23
(7) |
24
(8) |
25
(13) |
26
(14) |
27
(14) |
28
(5) |
|
29
(6) |
30
(21) |
31
(14) |
|
|
|
|
|
From: <sv...@va...> - 2009-03-31 14:30:52
|
Author: sewardj
Date: 2009-03-31 15:30:39 +0100 (Tue, 31 Mar 2009)
New Revision: 9505
Log:
Fix race conditions in pthread startup code (Greg Parker).
Parent thread holds The Lock on behalf of the child thread while the
child does its prep. Further improvements may be possible.
Modified:
branches/DARWIN/coregrind/m_syswrap/syswrap-amd64-darwin.c
branches/DARWIN/coregrind/m_syswrap/syswrap-darwin.c
branches/DARWIN/coregrind/m_syswrap/syswrap-x86-darwin.c
branches/DARWIN/coregrind/pub_core_threadstate.h
Modified: branches/DARWIN/coregrind/m_syswrap/syswrap-amd64-darwin.c
===================================================================
--- branches/DARWIN/coregrind/m_syswrap/syswrap-amd64-darwin.c 2009-03-31 10:46:37 UTC (rev 9504)
+++ branches/DARWIN/coregrind/m_syswrap/syswrap-amd64-darwin.c 2009-03-31 14:30:39 UTC (rev 9505)
@@ -291,7 +291,10 @@
// VG_(printf)("pthread_hijack pthread %p, machthread %p, func %p, arg %p, stack %p, flags %p, stack %p\n", self, kport, func, func_arg, stacksize, flags, sp);
-
+ // Wait for parent thread's permission.
+ // The parent thread holds V's lock on our behalf.
+ semaphore_wait(tst->os_state.child_go);
+
// Set thread's registers
// Do this FIRST because some code below tries to collect a backtrace,
// which requires valid register data.
@@ -336,7 +339,8 @@
// Tell parent thread's POST(sys_bsdthread_create) that we're done
// initializing registers and mapping memory.
- semaphore_signal(tst->os_state.bsdthread_create_sema);
+ semaphore_signal(tst->os_state.child_done);
+ // LOCK IS GONE BELOW THIS POINT
// Go!
call_on_new_stack_0_1(tst->os_state.valgrind_stack_init_SP, 0,
Modified: branches/DARWIN/coregrind/m_syswrap/syswrap-darwin.c
===================================================================
--- branches/DARWIN/coregrind/m_syswrap/syswrap-darwin.c 2009-03-31 10:46:37 UTC (rev 9504)
+++ branches/DARWIN/coregrind/m_syswrap/syswrap-darwin.c 2009-03-31 14:30:39 UTC (rev 9505)
@@ -5634,21 +5634,27 @@
tst->os_state.func_arg = (Addr)ARG2;
ARG2 = (Word)tst;
- // Create a semaphore that pthread_hijack will signal once it starts.
- // POST(sys_bsdthread_create) needs to wait for the new memory map to appear.
- semaphore_create(mach_task_self(), &tst->os_state.bsdthread_create_sema,
+ // Create a semaphore that pthread_hijack will signal once it starts
+ // POST(sys_bsdthread_create) needs to wait for the new memory map to appear
+ semaphore_create(mach_task_self(), &tst->os_state.child_go,
SYNC_POLICY_FIFO, 0);
+ semaphore_create(mach_task_self(), &tst->os_state.child_done,
+ SYNC_POLICY_FIFO, 0);
}
POST(sys_bsdthread_create)
{
- // Wait for pthread_hijack to finish on new thread.
- // Otherwise V thinks the new pthread struct is still
- // unmapped when we return to libc, causing false errors
+ // Tell new thread's pthread_hijack to proceed, and wait for it to finish.
+ // We hold V's lock on the child's behalf.
+ // If we return before letting pthread_hijack do its thing, V thinks
+ // the new pthread struct is still unmapped when we return to libc,
+ // causing false errors.
ThreadState *tst = (ThreadState *)ARG2;
- semaphore_wait(tst->os_state.bsdthread_create_sema);
- semaphore_destroy(mach_task_self(), tst->os_state.bsdthread_create_sema);
+ semaphore_signal(tst->os_state.child_go);
+ semaphore_wait(tst->os_state.child_done);
+ semaphore_destroy(mach_task_self(), tst->os_state.child_go);
+ semaphore_destroy(mach_task_self(), tst->os_state.child_done);
// fixme semaphore destroy needed when thread creation fails
// fixme probably other cleanup too
Modified: branches/DARWIN/coregrind/m_syswrap/syswrap-x86-darwin.c
===================================================================
--- branches/DARWIN/coregrind/m_syswrap/syswrap-x86-darwin.c 2009-03-31 10:46:37 UTC (rev 9504)
+++ branches/DARWIN/coregrind/m_syswrap/syswrap-x86-darwin.c 2009-03-31 14:30:39 UTC (rev 9505)
@@ -278,14 +278,12 @@
ThreadState *tst = (ThreadState *)func_arg;
VexGuestX86State *vex = &tst->arch.vex;
- /* JRS: attempts here to acquire the bigLock (_LL) cause threaded
- programs to hang. Implication is that some other thread holds
- the bigLock at this point. Is that OK? I don't understand
- this. */
-
// VG_(printf)("pthread_hijack pthread %p, machthread %p, func %p, arg %p, stack %p, flags %p, stack %p\n", self, kport, func, func_arg, stacksize, flags, sp);
-
+ // Wait for parent thread's permission.
+ // The parent thread holds V's lock on our behalf.
+ semaphore_wait(tst->os_state.child_go);
+
// Set thread's registers
// Do this FIRST because some code below tries to collect a backtrace,
// which requires valid register data.
@@ -329,14 +327,15 @@
}
VG_(am_do_sync_check)("after", "pthread_hijack", 0);
- // Tell parent thread's POST(sys_bsdthread_create) that we're done
- // initializing registers and mapping memory.
- semaphore_signal(tst->os_state.bsdthread_create_sema);
-
// DDD: should this be here rather than in POST(sys_bsdthread_create)?
// But we don't have ptid here...
//VG_TRACK ( pre_thread_ll_create, ptid, tst->tid );
+ // Tell parent thread's POST(sys_bsdthread_create) that we're done
+ // initializing registers and mapping memory.
+ semaphore_signal(tst->os_state.child_done);
+ // LOCK IS GONE BELOW THIS POINT
+
// Go!
call_on_new_stack_0_1(tst->os_state.valgrind_stack_init_SP, 0,
start_thread_NORETURN, (Word)tst);
Modified: branches/DARWIN/coregrind/pub_core_threadstate.h
===================================================================
--- branches/DARWIN/coregrind/pub_core_threadstate.h 2009-03-31 10:46:37 UTC (rev 9504)
+++ branches/DARWIN/coregrind/pub_core_threadstate.h 2009-03-31 14:30:39 UTC (rev 9505)
@@ -160,7 +160,8 @@
Addr func_arg;
// Synchronization between child thread and parent thread's POST wrapper
- semaphore_t bsdthread_create_sema;
+ semaphore_t child_go;
+ semaphore_t child_done;
// Workqueue re-entry
// (setjmp in PRE(workq_ops), longjmp in wqthread_hijack)
|
|
From: Bart V. A. <bar...@gm...> - 2009-03-31 11:16:57
|
On Tue, Mar 31, 2009 at 12:08 PM, Konstantin Serebryany
<kon...@gm...> wrote:
> There are at least two ways to fix this:
> - somehow recognize this h-b dependency introduced by libpthread
> - clear the state of stack/tls memory.
>
> Second way is preferable since it will not hide real races...
When the Valgrind core notifies a tool that a thread exits the stack
pointer of that thread is still below the top of the stack because of
the area reserved by the NPTL. In the DRD tool the state of the
top-of-stack area is cleared explicitly when a thread exits. The
following code in DRD's pre_thread_ll_exit handler performs this task:
drd_stop_using_mem(DRD_(thread_get_stack_min)(drd_tid),
DRD_(thread_get_stack_max)(drd_tid)
- DRD_(thread_get_stack_min)(drd_tid),
True);
Bart.
|
|
From: <sv...@va...> - 2009-03-31 10:46:44
|
Author: bart
Date: 2009-03-31 11:46:37 +0100 (Tue, 31 Mar 2009)
New Revision: 9504
Log:
Another test plan update.
Modified:
trunk/drd/Testing.txt
Modified: trunk/drd/Testing.txt
===================================================================
--- trunk/drd/Testing.txt 2009-03-31 10:46:00 UTC (rev 9503)
+++ trunk/drd/Testing.txt 2009-03-31 10:46:37 UTC (rev 9504)
@@ -11,7 +11,8 @@
4. Run the regression tests as follows:
perl tests/vg_regtest drd
5. Run Konstantin's regression tests:
- svn checkout http://data-race-test.googlecode.com/svn/trunk drt
+ mkdir -p drt/unittest
+ svn checkout http://data-race-test.googlecode.com/svn/trunk/unittest drt/unittest
make -C drt/unittest -s all
./vg-in-place --tool=drd --check-stack-var=yes drt/unittest/racecheck_unittest 2>&1|less
6. Test the slowdown for matinv for various matrix sizes via the script
|
|
From: <sv...@va...> - 2009-03-31 10:46:12
|
Author: bart Date: 2009-03-31 11:46:00 +0100 (Tue, 31 Mar 2009) New Revision: 9503 Log: Updated ignore list. Modified: trunk/drd/tests/ Property changes on: trunk/drd/tests ___________________________________________________________________ Name: svn:ignore - *.stderr.diff* *.stderr.out *.stdout.diff* *.stdout.out .deps atomic_var bar_bad bar_trivial boost_thread circular_buffer drd_bitmap_test fp_race hg01_all_ok hg02_deadlock hg03_inherit hg04_race hg05_race2 hg06_readshared hold_lock linuxthreads_det Makefile Makefile.in matinv memory_allocation monitor_example new_delete omp_matinv omp_prime omp_printf pth_barrier pth_barrier_race pth_barrier_reinit pth_broadcast pth_cancel_locked pth_cond_race pth_create_chain pth_detached pth_detached_sem pth_inconsistent_cond_wait pth_spinlock qt4_mutex qt4_rwlock qt4_semaphore recursive_mutex rwlock_race rwlock_test sem_as_mutex sigalrm tc01_simple_race tc02_simple_tls tc03_re_excl tc04_free_lock tc05_simple_race tc06_two_races tc07_hbl1 tc08_hbl2 tc09_bad_unlock tc10_rec_lock tc11_XCHG tc12_rwl_trivial tc13_laog1 tc15_laog_lockdel tc16_byterace tc17_sembar tc18_semabuse tc19_shadowmem tc20_verifywrap tc21_pthonce tc22_exit_w_lock tc23_bogus_condwait tc24_nonzero_sem trylock vg_regtest.tmp* + *.stderr.diff* *.stderr.out *.stdout.diff* *.stdout.out .deps atomic_var bar_bad bar_trivial boost_thread circular_buffer drd_bitmap_test fp_race hg01_all_ok hg02_deadlock hg03_inherit hg04_race hg05_race2 hg06_readshared hold_lock linuxthreads_det Makefile Makefile.in matinv memory_allocation monitor_example new_delete omp_matinv omp_prime omp_printf pth_barrier pth_barrier_race pth_barrier_reinit pth_broadcast pth_cancel_locked pth_cond_race pth_create_chain pth_detached pth_detached_sem pth_inconsistent_cond_wait pth_process_shared_mutex pth_spinlock qt4_mutex qt4_rwlock qt4_semaphore recursive_mutex rwlock_race rwlock_test sem_as_mutex sigalrm tc01_simple_race tc02_simple_tls tc03_re_excl tc04_free_lock tc05_simple_race tc06_two_races tc07_hbl1 tc08_hbl2 tc09_bad_unlock tc10_rec_lock tc11_XCHG tc12_rwl_trivial tc13_laog1 tc15_laog_lockdel tc16_byterace tc17_sembar tc18_semabuse tc19_shadowmem tc20_verifywrap tc21_pthonce tc22_exit_w_lock tc23_bogus_condwait tc24_nonzero_sem trylock vg_regtest.tmp* |
|
From: <sv...@va...> - 2009-03-31 10:37:06
|
Author: tom
Date: 2009-03-31 11:36:58 +0100 (Tue, 31 Mar 2009)
New Revision: 9502
Log:
Add SIOCGSTAMPNS support. Fixes #188530.
Modified:
trunk/coregrind/m_syswrap/syswrap-linux.c
trunk/include/vki/vki-amd64-linux.h
trunk/include/vki/vki-ppc32-linux.h
trunk/include/vki/vki-ppc64-linux.h
trunk/include/vki/vki-x86-linux.h
Modified: trunk/coregrind/m_syswrap/syswrap-linux.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-linux.c 2009-03-31 09:41:37 UTC (rev 9501)
+++ trunk/coregrind/m_syswrap/syswrap-linux.c 2009-03-31 10:36:58 UTC (rev 9502)
@@ -3526,6 +3526,9 @@
case VKI_SIOCGSTAMP:
PRE_MEM_WRITE( "ioctl(SIOCGSTAMP)", ARG3, sizeof(struct vki_timeval));
break;
+ case VKI_SIOCGSTAMPNS:
+ PRE_MEM_WRITE( "ioctl(SIOCGSTAMPNS)", ARG3, sizeof(struct vki_timespec));
+ break;
/* SIOCOUTQ is an ioctl that, when called on a socket, returns
the number of bytes currently in that socket's send buffer.
It writes this value as an int to the memory location
@@ -4569,6 +4572,9 @@
case VKI_SIOCGSTAMP:
POST_MEM_WRITE( ARG3, sizeof(struct vki_timeval) );
break;
+ case VKI_SIOCGSTAMPNS:
+ POST_MEM_WRITE( ARG3, sizeof(struct vki_timespec) );
+ break;
/* SIOCOUTQ is an ioctl that, when called on a socket, returns
the number of bytes currently in that socket's send buffer.
It writes this value as an int to the memory location
Modified: trunk/include/vki/vki-amd64-linux.h
===================================================================
--- trunk/include/vki/vki-amd64-linux.h 2009-03-31 09:41:37 UTC (rev 9501)
+++ trunk/include/vki/vki-amd64-linux.h 2009-03-31 10:36:58 UTC (rev 9502)
@@ -281,9 +281,10 @@
// From linux-2.6.9/include/asm-x86_64/sockios.h
//----------------------------------------------------------------------
-#define VKI_SIOCSPGRP 0x8902
-#define VKI_SIOCGPGRP 0x8904
-#define VKI_SIOCGSTAMP 0x8906 /* Get stamp */
+#define VKI_SIOCSPGRP 0x8902
+#define VKI_SIOCGPGRP 0x8904
+#define VKI_SIOCGSTAMP 0x8906 /* Get stamp (timeval) */
+#define VKI_SIOCGSTAMPNS 0x8907 /* Get stamp (timespec) */
//----------------------------------------------------------------------
// From linux-2.6.9/include/asm-x86_64/stat.h
Modified: trunk/include/vki/vki-ppc32-linux.h
===================================================================
--- trunk/include/vki/vki-ppc32-linux.h 2009-03-31 09:41:37 UTC (rev 9501)
+++ trunk/include/vki/vki-ppc32-linux.h 2009-03-31 10:36:58 UTC (rev 9502)
@@ -342,9 +342,10 @@
#define VKI_SOL_SOCKET 1
#define VKI_SO_TYPE 3
-#define VKI_SIOCSPGRP 0x8902
-#define VKI_SIOCGPGRP 0x8904
-#define VKI_SIOCGSTAMP 0x8906 /* Get stamp */
+#define VKI_SIOCSPGRP 0x8902
+#define VKI_SIOCGPGRP 0x8904
+#define VKI_SIOCGSTAMP 0x8906 /* Get stamp (timeval) */
+#define VKI_SIOCGSTAMPNS 0x8907 /* Get stamp (timespec) */
//----------------------------------------------------------------------
// From linux-2.6.10/include/asm-ppc/stat.h
Modified: trunk/include/vki/vki-ppc64-linux.h
===================================================================
--- trunk/include/vki/vki-ppc64-linux.h 2009-03-31 09:41:37 UTC (rev 9501)
+++ trunk/include/vki/vki-ppc64-linux.h 2009-03-31 10:36:58 UTC (rev 9502)
@@ -404,7 +404,8 @@
#define VKI_SIOCSPGRP 0x8902
#define VKI_SIOCGPGRP 0x8904
-#define VKI_SIOCGSTAMP 0x8906 /* Get stamp */
+#define VKI_SIOCGSTAMP 0x8906 /* Get stamp (timeval) */
+#define VKI_SIOCGSTAMPNS 0x8907 /* Get stamp (timespec) */
//----------------------------------------------------------------------
// From linux-2.6.13/include/asm-ppc64/stat.h
Modified: trunk/include/vki/vki-x86-linux.h
===================================================================
--- trunk/include/vki/vki-x86-linux.h 2009-03-31 09:41:37 UTC (rev 9501)
+++ trunk/include/vki/vki-x86-linux.h 2009-03-31 10:36:58 UTC (rev 9502)
@@ -318,9 +318,10 @@
// From linux-2.6.8.1/include/asm-i386/sockios.h
//----------------------------------------------------------------------
-#define VKI_SIOCSPGRP 0x8902
-#define VKI_SIOCGPGRP 0x8904
-#define VKI_SIOCGSTAMP 0x8906 /* Get stamp */
+#define VKI_SIOCSPGRP 0x8902
+#define VKI_SIOCGPGRP 0x8904
+#define VKI_SIOCGSTAMP 0x8906 /* Get stamp (timeval) */
+#define VKI_SIOCGSTAMPNS 0x8907 /* Get stamp (timespec) */
//----------------------------------------------------------------------
// From linux-2.6.8.1/include/asm-i386/stat.h
|
|
From: Konstantin S. <kon...@gm...> - 2009-03-31 10:08:09
|
On Tue, Mar 31, 2009 at 2:05 PM, Konstantin Serebryany <kon...@gm...> wrote: > On Tue, Mar 31, 2009 at 2:03 PM, Julian Seward <js...@ac...> wrote: >> On Tuesday 31 March 2009, Konstantin Serebryany wrote: >>> The problem seems to be even worth. >>> I've got a false positive on a stack object. Both Helgrind and >>> ThreadSanitizer are affected. >>> The scenario is the same: >>> >>> - Thread1 starts >>> - Thread1 touches stack >>> - Thread1 ends >>> - Thread2 starts (and there is no happens-before relation between it >>> and Thread1) >>> - Thread2 touches stack >>> It may happen so that Thread2 will have it's stack in the same address >>> as Thread1. >>> Since there is no happens-before relation between threads, >>> ThreadSanitizer & Helgrind report a race. >> >> I know that libpthread re-uses stacks from finished threads for new >> threads, so as to avoid the overhead of munmapping them and then mmaping >> them for the new thread. But I don't see how it can reuse a stack for a >> new thread without knowing that the old thread is finished. In other words >> libpthread must know there is a h-b dependency there, even if TS and H don't >> see it. > > Oh, sure there is a h-b dependency somewhere inside pthread lib. But > we don't see it. > Since H is pure h-b, this h-b dependency is not done by pthread_mutex_lock. There are at least two ways to fix this: - somehow recognize this h-b dependency introduced by libpthread - clear the state of stack/tls memory. Second way is preferable since it will not hide real races... --kcc > > --kcc > >> >> Do you think this is a correct analysis? >> >> J >> > |
|
From: Konstantin S. <kon...@gm...> - 2009-03-31 10:05:43
|
On Tue, Mar 31, 2009 at 2:03 PM, Julian Seward <js...@ac...> wrote: > On Tuesday 31 March 2009, Konstantin Serebryany wrote: >> The problem seems to be even worth. >> I've got a false positive on a stack object. Both Helgrind and >> ThreadSanitizer are affected. >> The scenario is the same: >> >> - Thread1 starts >> - Thread1 touches stack >> - Thread1 ends >> - Thread2 starts (and there is no happens-before relation between it >> and Thread1) >> - Thread2 touches stack >> It may happen so that Thread2 will have it's stack in the same address >> as Thread1. >> Since there is no happens-before relation between threads, >> ThreadSanitizer & Helgrind report a race. > > I know that libpthread re-uses stacks from finished threads for new > threads, so as to avoid the overhead of munmapping them and then mmaping > them for the new thread. But I don't see how it can reuse a stack for a > new thread without knowing that the old thread is finished. In other words > libpthread must know there is a h-b dependency there, even if TS and H don't > see it. Oh, sure there is a h-b dependency somewhere inside pthread lib. But we don't see it. Since H is pure h-b, this h-b dependency is not done by pthread_mutex_lock. --kcc > > Do you think this is a correct analysis? > > J > |
|
From: Julian S. <js...@ac...> - 2009-03-31 09:59:35
|
On Tuesday 31 March 2009, Konstantin Serebryany wrote: > The problem seems to be even worth. > I've got a false positive on a stack object. Both Helgrind and > ThreadSanitizer are affected. > The scenario is the same: > > - Thread1 starts > - Thread1 touches stack > - Thread1 ends > - Thread2 starts (and there is no happens-before relation between it > and Thread1) > - Thread2 touches stack > It may happen so that Thread2 will have it's stack in the same address > as Thread1. > Since there is no happens-before relation between threads, > ThreadSanitizer & Helgrind report a race. I know that libpthread re-uses stacks from finished threads for new threads, so as to avoid the overhead of munmapping them and then mmaping them for the new thread. But I don't see how it can reuse a stack for a new thread without knowing that the old thread is finished. In other words libpthread must know there is a h-b dependency there, even if TS and H don't see it. Do you think this is a correct analysis? J |
|
From: <sv...@va...> - 2009-03-31 09:41:45
|
Author: sewardj
Date: 2009-03-31 10:41:37 +0100 (Tue, 31 Mar 2009)
New Revision: 9501
Log:
Another suppression for Darwin.
Modified:
branches/DARWIN/darwin9.supp
Modified: branches/DARWIN/darwin9.supp
===================================================================
--- branches/DARWIN/darwin9.supp 2009-03-30 18:16:30 UTC (rev 9500)
+++ branches/DARWIN/darwin9.supp 2009-03-31 09:41:37 UTC (rev 9501)
@@ -32,6 +32,15 @@
}
{
+ mach_msg_trap-4
+ Memcheck:Param
+ mach_msg(msg.msgh_remote_port)
+ fun:mach_msg_trap
+ obj:/System/Library/Frameworks/CoreFoundation*
+ obj:/System/Library/Frameworks/CoreFoundation*
+}
+
+{
macos-Cond-1
Memcheck:Cond
fun:GetVariationInfoFromName
|
|
From: Konstantin S. <kon...@gm...> - 2009-03-31 09:33:56
|
The problem seems to be even worth. I've got a false positive on a stack object. Both Helgrind and ThreadSanitizer are affected. The scenario is the same: - Thread1 starts - Thread1 touches stack - Thread1 ends - Thread2 starts (and there is no happens-before relation between it and Thread1) - Thread2 touches stack It may happen so that Thread2 will have it's stack in the same address as Thread1. Since there is no happens-before relation between threads, ThreadSanitizer & Helgrind report a race. % ~/valgrind/trunk/Inst/bin/valgrind --tool=helgrind ./racecheck_unittest 131 ... ==23797== Possible data race during write of size 4 at 0x1282b4fc by thread #11 ==23797== at 0x403093: test131::RealWorker() (racecheck_unittest.cc:6066) ==23797== by 0x41E9F8: MyThread::ThreadBody(MyThread*) (thread_wrappers_pthread.h:320) ==23797== by 0xD54070F: mythread_wrapper (hg_intercepts.c:194) ==23797== by 0xD7490C9: start_thread (in /usr/grte/v1/lib64/libpthread-2.3.6.so) ==23797== by 0xE1AF811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so) ==23797== This conflicts with a previous write of size 4 by thread #9 ==23797== at 0x403093: test131::RealWorker() (racecheck_unittest.cc:6066) ==23797== by 0x41E9F8: MyThread::ThreadBody(MyThread*) (thread_wrappers_pthread.h:320) ==23797== by 0xD54070F: mythread_wrapper (hg_intercepts.c:194) ==23797== by 0xD7490C9: start_thread (in /usr/grte/v1/lib64/libpthread-2.3.6.so) ==23797== by 0xE1AF811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so) It looks like neither Helgrind nor ThreadSanitizer clears the state of the stack memory (and TLS data) after a thread dies. Any idea? --kcc On Mon, Mar 30, 2009 at 5:34 PM, Nicholas Nethercote <n.n...@gm...> wrote: > On Mon, Mar 30, 2009 at 8:17 AM, Konstantin Serebryany > <kon...@gm...> wrote: >> Hi valgrind developers, >> >> Does valgrind core do something special about TLS (thread-local storage)? >> >> I've recently discovered a false positive in ThreadSanitizer which is >> caused by TLS. >> Helgrind also emits a race report on the same test case. >> Test: >> // - Thread1 starts >> // - Thread1 touches per_thread_global >> // - Thread1 ends >> // - Thread2 starts (and there is no happens-before relation between >> it and Thread1) >> // - Thread2 touches per_thread_global >> // It may happen so that Thread2 will have per_thread_global in the same address >> // as Thread1. Since there is no happens-before relation between threads, >> // ThreadSanitizer reports a race. >> The runable code is in >> http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc?spec=svn939&r=939#6017 >> >> As I understand, the valgrind core handles stack allocation and >> deallocation itself. >> All that tool needs to do is to call VG_(track_new_mem_stack) and similar. >> Is there anything like this for TLS? > > No; it's never come up before... > > Nick > |
|
From: Bart V. A. <bar...@gm...> - 2009-03-31 08:25:03
|
Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) started at 2009-03-31 02:00:02 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 407 tests, 36 stderr failures, 9 stdout failures, 0 post failures == exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) helgrind/tests/hg05_race2 (stderr) memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/linux/mremap (stderr) none/tests/linux/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) |
|
From: Tom H. <th...@cy...> - 2009-03-31 03:11:11
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-03-31 03:05:06 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 478 tests, 4 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) |
|
From: Tom H. <th...@cy...> - 2009-03-31 03:04:53
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-03-31 03:20:03 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 487 tests, 0 stderr failures, 0 stdout failures, 0 post failures == |
|
From: Tom H. <th...@cy...> - 2009-03-31 02:47:14
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-03-31 03:10:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 484 tests, 4 stderr failures, 1 stdout failure, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) none/tests/linux/mremap2 (stdout) |