|
From: Jorge M. <jor...@gm...> - 2010-05-29 17:01:05
|
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 <and...@gm...> 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_broadcast@* (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== ==27651== condition variable has not been initialized: cond 0x6174420 ==27651== at 0x4C267B9: pthread_cond_broadcast@* (drd_pthread_intercepts.c:756) ==27651== by 0x66D7F1A: boost::log_mt_posix::basic_core<char>::get() (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0xB5087C: boost::log_mt_posix::sources::basic_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex> >::basic_logger() (basic_logger.hpp:122) ==27651== by 0xB4F166: boost::log_mt_posix::sources::basic_severity_logger<boost::log_mt_posix::sources::basic_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex> >, util::logging::severity_level>::basic_severity_logger() (severity_feature.hpp:169) ==27651== by 0xB4DA3D: boost::log_mt_posix::sources::basic_composite_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex>, boost::mpl::vector1<boost::log_mt_posix::sources::severity<util::logging::severity_level> > >::basic_composite_logger() (basic_logger.hpp:391) ==27651== by 0xB4C771: boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>::severity_logger_mt() (severity_logger.hpp:77) ==27651== by 0xB4BA3C: __static_initialization_and_destruction_0(int, int) (Logging.cpp:35) ==27651== by 0xB4BAC6: global constructors keyed to _ZN4util7logging3aux9theLoggerE (Logging.cpp:215) ==27651== by 0xB58095: ??? (in /home/jorge/vc/ripe/bin/server/ripe-server) ==27651== by 0x9D3732: ??? (in /home/jorge/vc/ripe/bin/server/ripe-server) ==27651== ==27651== condition variable has not been initialized: cond 0x6174420 ==27651== at 0x4C267B9: pthread_cond_broadcast@* (drd_pthread_intercepts.c:756) ==27651== by 0x5F6AD14: ??? (in /usr/local/lib/libboost_thread.so.1.42.0) ==27651== by 0x5F6AD48: boost::detail::get_current_thread_data() (in /usr/local/lib/libboost_thread.so.1.42.0) ==27651== by 0x5F6AD68: boost::detail::find_tss_data(void const*) (in /usr/local/lib/libboost_thread.so.1.42.0) ==27651== by 0x5F6ADD8: boost::detail::get_tss_data(void const*) (in /usr/local/lib/libboost_thread.so.1.42.0) ==27651== by 0x66D6FAB: boost::log_mt_posix::basic_core<char>::implementation::init_thread_data() (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x66D7619: boost::log_mt_posix::basic_core<char>::open_record(boost::log_mt_posix::basic_attribute_set<char> const&) (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x9F5432: boost::log_mt_posix::basic_record<char> boost::log_mt_posix::sources::basic_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex> >::open_record_unlocked<boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> >(boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> const&) (basic_logger.hpp:269) ==27651== by 0x9F3EDE: boost::log_mt_posix::basic_record<char> boost::log_mt_posix::sources::basic_severity_logger<boost::log_mt_posix::sources::basic_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex> >, util::logging::severity_level>::open_record_unlocked<boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> >(boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> const&) (severity_feature.hpp:226) ==27651== by 0x9F2511: boost::log_mt_posix::basic_record<char> boost::log_mt_posix::sources::basic_composite_logger<char, boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>, boost::log_mt_posix::sources::multi_thread_model<boost::log_mt_posix::aux::light_rw_mutex>, boost::mpl::vector1<boost::log_mt_posix::sources::severity<util::logging::severity_level> > >::open_record<boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> >(boost::parameter::aux::tagged_argument<boost::log_mt_posix::keywords::tag::severity, util::logging::severity_level const> const&) (basic_logger.hpp:509) ==27651== by 0xB4B5DF: util::logging::init(util::logging::severity_level, std::string const&) (Logging.cpp:190) ==27651== by 0xB49DA0: util::logging::init(std::string const&, std::string const&) (Logging.cpp:96) ==27651== ==27651== condition variable has not been initialized: cond 0x6174420 ==27651== at 0x4C267B9: pthread_cond_broadcast@* (drd_pthread_intercepts.c:756) ==27651== by 0x66D8D1A: ??? (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x66D9F43: boost::log_mt_posix::aux::stream_provider<char>::allocate_compound(boost::log_mt_posix::basic_record<char> const&) (in /usr/local/lib/libboost_log.so.1.42.0) ==27651== by 0x9F3F72: boost::log_mt_posix::aux::record_pump<boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level> >::record_pump(boost::log_mt_posix::sources::severity_logger_mt<util::logging::severity_level>&, boost::log_mt_posix::basic_record<char> const&) (record_ostream.hpp:293) ==27651== by 0xB4B5FC: util::logging::init(util::logging::severity_level, std::string const&) (record_ostream.hpp:330) ==27651== by 0xB49DA0: util::logging::init(std::string const&, std::string const&) (Logging.cpp:96) ==27651== by 0x9DB05C: util::Configuration::parseCommandLine(int, char**) (Configuration.hpp:176) ==27651== by 0x9D6C5C: ripe_server::Configuration::Configuration(int, char**) (Configuration.cpp:70) ==27651== by 0xA48A86: main (posix_main.cpp:94) ==27651== |
|
From: Bart V. A. <bva...@ac...> - 2010-05-30 05:56:53
|
On Sat, May 29, 2010 at 7:00 PM, Jorge Moraleda <jor...@gm...> 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 <and...@gm...> > > 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_broadcast@* > (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 ? Thanks, Bart. |
|
From: Jorge M. <jor...@gm...> - 2010-05-30 07:56:33
|
On Sat, May 29, 2010 at 10:56 PM, Bart Van Assche <bva...@ac...> wrote: > On Sat, May 29, 2010 at 7:00 PM, Jorge Moraleda > <jor...@gm...> 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 <and...@gm...> >> >> 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_broadcast@* >> (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. |
|
From: Jorge M. <jor...@gm...> - 2010-06-02 01:12:11
|
On Sun, May 30, 2010 at 12:56 AM, Jorge Moraleda <jor...@gm...> wrote: > On Sat, May 29, 2010 at 10:56 PM, Bart Van Assche <bva...@ac...> wrote: >> On Sat, May 29, 2010 at 7:00 PM, Jorge Moraleda >> <jor...@gm...> 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 <and...@gm...> >>> >>> 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_broadcast@* >>> (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_broadcast@* (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) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. |
|
From: Bart V. A. <bva...@ac...> - 2010-06-02 19:35:10
|
On Wed, Jun 2, 2010 at 3:12 AM, Jorge Moraleda <jor...@gm...> wrote: > > On Sun, May 30, 2010 at 12:56 AM, Jorge Moraleda > <jor...@gm...> wrote: > > On Sat, May 29, 2010 at 10:56 PM, Bart Van Assche <bva...@ac...> wrote: > >> On Sat, May 29, 2010 at 7:00 PM, Jorge Moraleda > >> <jor...@gm...> 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 <and...@gm...> > >>> > >>> 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_broadcast@* > >>> (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_broadcast@* > (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_broadcast@* (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. Bart. |
|
From: Julian S. <js...@ac...> - 2010-06-03 08:38:52
|
> 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 ? I think this is unrelated to the Valgrind core. If I understand correctly, you're asking about the relative order of calling of a global constructor in vgpreload_drd-amd64-linux.so and a global constructor in libboost_log.so. That is a question for ld.so, and I think in this case you get no guarantees. (but am not sure about that). The fact that ld.so is running on the virtual cpu, not the real one, doesn't matter. J |
|
From: Jorge M. <jor...@gm...> - 2010-06-02 20:04:51
|
On Wed, Jun 2, 2010 at 12:35 PM, Bart Van Assche <bva...@ac...> wrote: > On Wed, Jun 2, 2010 at 3:12 AM, Jorge Moraleda <jor...@gm...> wrote: >> >> On Sun, May 30, 2010 at 12:56 AM, Jorge Moraleda >> <jor...@gm...> wrote: >> > On Sat, May 29, 2010 at 10:56 PM, Bart Van Assche <bva...@ac...> wrote: >> >> On Sat, May 29, 2010 at 7:00 PM, Jorge Moraleda >> >> <jor...@gm...> 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 <and...@gm...> >> >>> >> >>> 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_broadcast@* >> >>> (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_broadcast@* >> (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_broadcast@* (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. > |
|
From: Julian S. <js...@ac...> - 2010-06-02 21:33:25
|
> 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. This a temporary problem caused by a recent change in the way the tool executables are linked, r11141. For details see https://bugs.kde.org/show_bug.cgi?id=193413#c18 I am trying to figure out how to fix it, with zero success so far. Any suggestions gratefully received :-) J |
|
From: Bart V. A. <bva...@ac...> - 2010-06-03 05:56:02
|
On Wed, Jun 2, 2010 at 10:04 PM, Jorge Moraleda <jor...@gm...> wrote: > [ ... ] > > 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. You can use the following as a temporary workaround for the mmap() error message: cd valgrind svn merge r11141:11140 . svn revert coregrind/link_tool_exe.c Bart. |