On Wed, Jun 2, 2010 at 12:35 PM, Bart Van Assche <[email protected]> wrote:
> On Wed, Jun 2, 2010 at 3:12 AM, Jorge Moraleda <[email protected]> 
> wrote:
>>
>> On Sun, May 30, 2010 at 12:56 AM, Jorge Moraleda
>> <[email protected]> wrote:
>> > On Sat, May 29, 2010 at 10:56 PM, Bart Van Assche <[email protected]> 
>> > wrote:
>> >> On Sat, May 29, 2010 at 7:00 PM, Jorge Moraleda
>> >> <[email protected]> wrote:
>> >>>
>> >>> I submitted a condition variable not initialized detected with
>> >>> valgrind drd to the boost mailing list, but they report that it is a
>> >>> false alarm:
>> >>>
>> >>> Date: Sat, 29 May 2010 09:29:23 +0400
>> >>> From: Andrey Semashev <[email protected]>
>> >>>
>> >>> On 05/29/2010 02:06 AM, Jorge Moraleda wrote:
>> >>> > When testing boost.log for race conditions using valgrind drd, some
>> >>> > non initialized condition variables are reported at initialization
>> >>> > time. I am using Valgrind-3.6.0.SVN and gcc version 4.4.4 (Debian
>> >>> > 4.4.4-1).
>> >>>
>> >>> It looks like a false alarm. The condition variable is defined and used
>> >>> by boost::once, and it is initialized statically in the Boost.Thread
>> >>> library.
>> >>>
>> >>> > These are the valgrind error messages:
>> >>>
>> >>> ==27651== condition variable has not been initialized: cond 0x6174420
>> >>> ==27651==    at 0x4C267B9: pthread_cond_broadc...@*
>> >>> (drd_pthread_intercepts.c:756)
>> >>> ==27651==    by 0x66DBCD2: ??? (in /usr/local/lib/libboost_log.so.1.42.0)
>> >>> ==27651==    by 0x6719E85: ??? (in /usr/local/lib/libboost_log.so.1.42.0)
>> >>> ==27651==    by 0x66C4BD2: ??? (in /usr/local/lib/libboost_log.so.1.42.0)
>> >>> ==27651==    by 0x7FF000561: ???
>> >>> ==27651==    by 0x722F63762F656771: ???
>> >>> ==27651==    by 0x2F6E69622F657068: ???
>> >>> ==27651==    by 0x722F726576726572: ???
>> >>> ==27651==    by 0x767265732D657068: ???
>> >>> ==27651==    by 0x2D2D00772D007264: ???
>> >>> ==27651==    by 0x72635F776F6C6C60: ???
>> >>> ==27651==    by 0x62645F65746164: ???
>> >>> ==27651==
>> >>> [ ... ]
>> >>
>> >> Until version 3.5.0 DRD was complaining about every condition variable
>> >> not initialized by calling pthread_cond_init(). Statically initialized
>> >> condition variables should be handled properly by trunk r11139. Are
>> >> you familiar with building Valgrind from the trunk ? If so, can you
>> >> please test this fix ?
>> >
>> > Those errors were obtained with version 3.6.0 from svn compiled a few
>> > weeks ago. I will download the latest one on Tuesday and try it.
>>
>> After getting the latest valgrind from svn earlier today and rerunning
>> my program I get the following error at start time (see below)
>> followed by valgrind's termination. (as a sanity check, memcheck has
>> no problem running). I have also upgraded boost log (which I run from
>> svn) and my kernel (debian sid). I have no problem using drd on other
>> programs (see separate message).
>>
>> ==18783== drd, a thread error detector
>> ==18783== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche.
>> ==18783== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright 
>> info
>> ==18783== Command: /home/jorge/vc/ripe/bin/features/compute-features
>> ==18783==
>>
>> drd: drd_cond.c:420 (vgDrd_cond_pre_broadcast): Assertion
>> 'DRD_(pthread_cond_initializer)' failed.
>> ==18783==    at 0x38018C57: report_and_quit (m_libcassert.c:191)
>> ==18783==    by 0x38018E90: vgPlain_assert_fail (m_libcassert.c:265)
>> ==18783==    by 0x38002AEB: vgDrd_cond_pre_broadcast (drd_cond.c:420)
>> ==18783==    by 0x38001D89: handle_client_request (drd_clientreq.c:359)
>> ==18783==    by 0x3805380E: vgPlain_scheduler (scheduler.c:1560)
>> ==18783==    by 0x3807CB14: run_a_thread_NORETURN (syswrap-linux.c:94)
>>
>> sched status:
>>  running_tid=1
>>
>> Thread 1: status = VgTs_Runnable
>> ==18783==    at 0x4C287B9: pthread_cond_broadc...@*
>> (drd_pthread_intercepts.c:771)
>> ==18783==    by 0x679FCD2: ??? (in
>> /opt/boost/boost_1_42_0/stage/lib/libboost_log.so.1.42.0)
>> ==18783==    by 0x67DDE85: ??? (in
>> /opt/boost/boost_1_42_0/stage/lib/libboost_log.so.1.42.0)
>> ==18783==    by 0x6788BD2: ??? (in
>> /opt/boost/boost_1_42_0/stage/lib/libboost_log.so.1.42.0)
>> [ ... ]
>
> I have been able to reproduce this behavior with a version of
> libboost_log.so built with debug information and obtained the
> following call stack:
>
> Thread 1: status = VgTs_Runnable
> at 0x4C2AA69: pthread_cond_broadc...@* (drd_pthread_intercepts.c:771)
> by 0x405D54: void boost::call_once<void (*)()>(boost::once_flag&, void
> (*)()) (once.hpp:78)
> by 0x4ED1DAD: global constructors keyed to named_scope.cpp (in
> /usr/lib/libboost_log.so.1.43.0)
>
> This means that pthread_cond_broadcast() was called from a global
> constructor in libboost_log.so before the initialization function in
> vgpreload_drd-amd64-linux.so (DRD_(init)) was called. I was surprised
> seeing constructors being called in this order. Julian, is this a
> normal behavior of the Valgrind core ?
>
> To Jorge: the reported DRD issue should have been fixed by r11145.

Thank you. I just tried r11145. It stops both with drd and memcheck,
even in very small programs, after giving the following output:

valgrind: mmap(0x400000, 823296) failed in UME with error 22 (Invalid argument).
valgrind: this can be caused by executables with very large text, data
or bss segments.



>
> Bart.
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to