This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]