|
From: Konstantin S. <kon...@gm...> - 2009-10-20 14:23:46
|
Hi, I've recently found a false positive in ThreadSanitizer/Helgrind/DRD. 1. Access a var. 2. register atexit callback 3. call exit 4. in atexit callback access a var http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc?spec=svn1175&r=1175#6988 ==14652== Possible data race during write of size 4 at 0x63f17c by thread #1 ==14652== at 0x40390A: test152::AtExitCallback() (racecheck_unittest.cc:6994) ==14652== by 0xE120A5E: exit (in /usr/grte/v1/lib64/libc-2.3.6.so) ==14652== by 0xE10AB30: (below main) (in /usr/grte/v1/lib64/libc-2.3.6.so ) ==14652== This conflicts with a previous write of size 4 by thread #2 ==14652== at 0x4150E3: test152::AtExitThread() (racecheck_unittest.cc:6998) ==14652== by 0x42469F: MyThread::ThreadBody(MyThread*) (thread_wrappers_pthread.h:375) ==14652== by 0xD54A302: mythread_wrapper (hg_intercepts.c:201) ==14652== by 0xD7530C9: start_thread (in /usr/grte/v1/lib64/ libpthread-2.3.6.so) ==14652== by 0xE1B9811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so) The simplest way to fix this is to create a h-b arc between atexit() and exit(). I managed to intercept atexit(), but can't do it for exit(). Is there any dark magic associated with intercepting exit()? Thanks, --kcc |
|
From: Konstantin S. <kon...@gm...> - 2009-10-20 14:51:37
|
I've managed to intercept exit. http://code.google.com/p/data-race-test/source/detail?r=1176# You might want to do the same in helgrind/drd. --kcc On Tue, Oct 20, 2009 at 6:23 PM, Konstantin Serebryany < kon...@gm...> wrote: > Hi, > I've recently found a false positive in ThreadSanitizer/Helgrind/DRD. > > 1. Access a var. > 2. register atexit callback > 3. call exit > 4. in atexit callback access a var > > > http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc?spec=svn1175&r=1175#6988 > > ==14652== Possible data race during write of size 4 at 0x63f17c by thread > #1 > ==14652== at 0x40390A: test152::AtExitCallback() > (racecheck_unittest.cc:6994) > ==14652== by 0xE120A5E: exit (in /usr/grte/v1/lib64/libc-2.3.6.so) > ==14652== by 0xE10AB30: (below main) (in /usr/grte/v1/lib64/ > libc-2.3.6.so) > ==14652== This conflicts with a previous write of size 4 by thread #2 > ==14652== at 0x4150E3: test152::AtExitThread() > (racecheck_unittest.cc:6998) > ==14652== by 0x42469F: MyThread::ThreadBody(MyThread*) > (thread_wrappers_pthread.h:375) > ==14652== by 0xD54A302: mythread_wrapper (hg_intercepts.c:201) > ==14652== by 0xD7530C9: start_thread (in /usr/grte/v1/lib64/ > libpthread-2.3.6.so) > ==14652== by 0xE1B9811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so) > > The simplest way to fix this is to create a h-b arc between atexit() and > exit(). > I managed to intercept atexit(), but can't do it for exit(). > Is there any dark magic associated with intercepting exit()? > > Thanks, > > --kcc > > > > |
|
From: Bart V. A. <bar...@gm...> - 2009-10-20 18:10:50
|
On Tue, Oct 20, 2009 at 4:23 PM, Konstantin Serebryany <kon...@gm...> wrote: > > I've recently found a false positive in ThreadSanitizer/Helgrind/DRD. > 1. Access a var. > 2. register atexit callback > 3. call exit > 4. in atexit callback access a var > http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc?spec=svn1175&r=1175#6988 > ==14652== Possible data race during write of size 4 at 0x63f17c by thread #1 > ==14652== at 0x40390A: test152::AtExitCallback() (racecheck_unittest.cc:6994) > ==14652== by 0xE120A5E: exit (in /usr/grte/v1/lib64/libc-2.3.6.so) > ==14652== by 0xE10AB30: (below main) (in /usr/grte/v1/lib64/libc-2.3.6.so) > ==14652== This conflicts with a previous write of size 4 by thread #2 > ==14652== at 0x4150E3: test152::AtExitThread() (racecheck_unittest.cc:6998) > ==14652== by 0x42469F: MyThread::ThreadBody(MyThread*) (thread_wrappers_pthread.h:375) > ==14652== by 0xD54A302: mythread_wrapper (hg_intercepts.c:201) > ==14652== by 0xD7530C9: start_thread (in /usr/grte/v1/lib64/libpthread-2.3.6.so) > ==14652== by 0xE1B9811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so) Good catch -- thanks for sharing this information. Bart. |