This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: pthread_create()'s behavor?
Hi Paul,
Thanks for your help.
The trace showed that the map was rebalancing while the "newly created" thread tried to read it?? I am not sure how it is possible since I updated m_map before I created the pthread, and no other thread would attempt to modify the map, trigger the rebalancing.
Any hint?
Thanks in advance.
Cheers,
Hei
----- Original Message -----
From: Paul Pluzhnikov <ppluzhnikov@google.com>
To: Hei Chan <structurechart@yahoo.com>
Cc: Ángel González <keisial@gmail.com>; "libc-help@sourceware.org" <libc-help@sourceware.org>
Sent: Tuesday, April 17, 2012 4:02 PM
Subject: Re: pthread_create()'s behavor?
On Tue, Apr 17, 2012 at 3:41 PM, Hei Chan <structurechart@yahoo.com> wrote:
> Here is the complete and compile-able version:
Thank you. It is still missing "#include <stdio.h>", but the problem is
now clear.
> I suspect that the new thread starts running before object a is completely
> constructed; hence, accessing the member variable m_map of the incomplete
> object a might result in undefined behavior/segfault.
No, the problem has nothing to do with that.
Here is output from thread sanitizer
http://code.google.com/p/data-race-test/wiki/ThreadSanitizer
==3724== ThreadSanitizerValgrind r3628: hybrid=no
==3724== INFO: ThreadSanitizer memory limit: 8192MB
==3724== INFO: Allocating 256Mb (32 * 8M) for Segments.
==3724== INFO: Will allocate up to 640Mb for 'previous' stack traces.
found
doSomething
==3724== INFO: T1 has been created by T0. Use --announce-threads to
see the creation stack.
==3724== INFO: T0 is program's main thread
==3724== WARNING: Possible data race during write of size 8 at 0x7FFEFFF278: {{{
==3724==? ? T0 (L{}):
==3724==? ? #0? std::_Rb_tree_rebalance_for_erase /usr/lib/libstdc++.so.6.0.13
==3724==? ? #1? std::_Rb_tree::erase /usr/include/c++/4.4/bits/stl_tree.h:1347
==3724==? ? #2? std::map::erase /usr/include/c++/4.4/bits/stl_map.h:567
==3724==? ? #3? A::~A /g/tmp/t.cc:24
==3724==? ? #4? main /g/tmp/t.cc:50
==3724==? Concurrent read(s) happened at (OR AFTER) these points:
==3724==? ? T1 (L{}):
==3724==? ? #0? std::_Rb_tree::_M_begin
/usr/include/c++/4.4/bits/stl_tree.h:481
==3724==? ? #1? std::_Rb_tree::find /usr/include/c++/4.4/bits/stl_tree.h:1421
==3724==? ? #2? std::map::find /usr/include/c++/4.4/bits/stl_map.h:659
==3724==? ? #3? A::startThread /g/tmp/t.cc:36
==3724==? Location 0x7FFEFFF278 is 7552 bytes inside T0's stack
[0x7FFE800FF8,0x7FFF000FF8]
==3724==? ? Race verifier data: 0x4EB9B25,0x401224
==3724== }}}
...
You should now be able to understand exactly what your problem is.
Hope this helps.
--
Paul Pluzhnikov