|
From: John R. <jr...@ci...> - 2012-03-13 18:42:23
|
On 3/12/2012 9:49 AM, Bart Van Assche wrote: > > On 03/10/12 00:06, John Rocha wrote: > > I'm finding what appears to be a data race in the std::string class. Although I > > find that hard to believe. > > > > I am using libstdc++ 6.0.8, with g++ version 4.1.2 that is using the posix > > thread model, on a Linux machine running SuSE SLES10SP1 > > > > Linux <hostname> 2.6.16.46-0.12-smp #1 SMP Thu May 17 14:00:09 UTC 2007 > > i686 i686 i386 GNU/Linux > > > > My machine has 2 cores (or 4 hyper threads). > > > > My application is a multithreaded, using boost threads, which in turn is using > > posix pthreads under the sheets. > > > > > > Below is one of many reports that all seem to be variations on the same > > thing. If I read this correctly it is indicating that std::string in thread 1 > > and thread 8 are potentially racing. > > > > thread1 and thread8 are absolutely not sharing any strings. Thread8's string is > > a local stack string, and thread1's string appears to be another stack string > > from inside the libboost_program_options.so-1.43.0 > > > > Am I reading this correctly? That there is a data race in the string class? > > In old versions of libstdc++, yes. You might have run into gcc bug > #40518 (gcc.gnu.org/bugzilla/show_bug.cgi?id=40518). See also > http://stackoverflow.com/questions/3035313/cant-figure-out-where-race-condition-is-occuring. > > Bart. Hello Bart, Thank you for the stack overflow link. Many of my instances are indeed of the _M_mutate variety. A question though. What is the result of this issue? I'm not really able to determine the impact when I read through the GCC bug you referenced. It sounds like the GCC developers are stating that its been like this forever, and noone has complained, so its probably not really a problem, but they're going to fix it anyway. Also, from the GCC listing it indicates that its' known to fail in version 4.2.2, 4.3.2 and 4.4.3 and it was fixed in 4.4.4. Do you know what that version number applies too? Is it the gcc/g++ version? Or is it the version of the libstdc++ library? I ask because on our systems I see that we are gcc/g++ using 4.1.2, however, I also see that we have multiple verseions of the libstdc++ library, ranging from 4.1.2 up to 6.0.8. I was reading a FAQ aat gcc.gnu.org, and it made it sound like the shared object library could be much larger than actual version number "When running on GNU/Linux, libstdc++ 3.2.1 (shared library version 5.0.1) and later ....." from http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.linux_glibc Thank you for your help Bart, -=John [SUSE10.1]> gcc --version gcc (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [SUSE10.1]> g++ --version g++ (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [SUSE10.1]> find /{lib,usr/lib} -iname "*libstdc*" /usr/lib/libstdc++.so.5.0.7 /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6 /usr/lib/libstdc++.so.6.0.8 /usr/lib/gcc/i586-suse-linux/4.1.2/libstdc++.a /usr/lib/gcc/i586-suse-linux/4.1.2/libstdc++.la /usr/lib/gcc/i586-suse-linux/4.1.2/libstdc++.so /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so /usr/lib/libstdc++-libc6.1-1.so.2 /usr/lib/libstdc++-libc6.1-2.so.3 /usr/lib/libstdc++-libc6.2-2.so.3 /usr/lib/libstdc++.so.2.7.2 /usr/lib/libstdc++.so.2.7.2.8 /usr/lib/libstdc++.so.2.8 /usr/lib/libstdc++.so.2.8.0 /usr/lib/libstdc++.so.2.9 /usr/lib/libstdc++.so.2.9.0 /usr/lib/libstdc++.la |