On Wed, Dec 9, 2009 at 2:23 PM, Mathieu Malaterre <[email protected]> wrote: > I am discovering DRD tool today, after reading the following documentation: > http://valgrind.org/docs/manual/drd-manual.html#drd-manual.data-races > > I am trying to apply this to the following output (*). According to > the doc, I need to: > > "Start at the bottom of both call stacks, and count the number stack > frames with identical function name, file name and line number. In the > above example the three bottommost frames are identical (clone, > start_thread and vg_thread_wrapper). " > > However in my case, there does not seems to be any identical > function name/filename/line number. can I still deduce anything from > that particular output ? > > (*) > ==15069== Thread 2: > ==15069== Conflicting load by thread 2 at 0x00650958 size 8 > ==15069== at 0x77FEEFD: std::basic_ostream<char, > std::char_traits<char> >& std::__ostream_insert<char, > std::char_traits<char> >(std::basic_ostream<char, > std::char_traits<char> >&, char const*, long) (in > /usr/lib/libstdc++.so.6.0.13)
The above tells you that the conflicting load was caused by a memory access inside the libstdc++ code for sending a string (char const*) to a stream. As you can see in the source code of this function (see also file libstdc++-v3/include/bits/ostream_insert.h in the gcc source tree), this function creates a temporary object of type sentry (see also http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-3.4/classstd_1_1basic__istream_1_1sentry.html for more information). The constructor of sentry objects uses the locale to find out whether a character is whitespace or not. [...] > ==15069== Allocation context: BSS section of > de/Csm-gcc/CodeGenerator/Testing/GeneratedEpidemiology/Bin/main This tells you that the conflicting access occurred on a variable in a BSS section (a global or a static variable). [ ... ] > ==15069== Other segment end (thread 1) > ==15069== at 0x4C26668: pthread_mutex_lock (drd_pthread_intercepts.c:580) > ==15069== by 0x77CE1BE: std::locale::locale() (in > /usr/lib/libstdc++.so.6.0.13) > ==15069== by 0x77CA82F: std::ios_base::_M_init() (in > /usr/lib/libstdc++.so.6.0.13) > ==15069== by 0x77DF228: std::basic_ios<char, std::char_traits<char> >>::init(std::basic_streambuf<char, std::char_traits<char> >*) (in > /usr/lib/libstdc++.so.6.0.13) > ==15069== by 0x7802652: std::basic_stringstream<char, > std::char_traits<char>, std::allocator<char> >>::basic_stringstream(std::_Ios_Openmode) (in > /usr/lib/libstdc++.so.6.0.13) [ ... ] The above information is an additional hint that the conflicting access is probably caused by access to locale information. What is not yet clear to me is whether the conflicting memory access is caused by libstdc++ or by the code using libstdc++, e.g. because a stringstream object is being accessed from more than one thread. Bart. ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
