First, please excuse the length of this message, I just want to provide a clear picture of what's happening. I'm interested in using the gcc mudflap feature (sort of valgrind/purify implemented in the compiler) with the boost libraries. http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging http://gcc-hk.internet.bs/summit/2003/mudflap.pdf Unfortunately, I'm running into serious problems. Preliminaries: I'm using gcc 4.2, boost 1.34.1, Ubuntu Linux Hardy Heron. I found a message from 2006-07-31 discussing mudflap (http://lists.boost.org/boost-build/2006/07/14546.php), but it only refers to build flags. Now for the issue, writing a simple test case (which appears to run correctly without mudflap instrumentation): #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE(mudflap) { } And compiling and running yields: $ g++ -g -fmudflapth -c -o mudflapTest.o mudflapTest.cpp $ g++ -g -fmudflapth mudflapTest.o /usr/lib/libmudflapth.so.0 \ -lboost_unit_test_framework -lboost_thread -o mudflapTest $ ./mudflapTest ******* mudflap violation 1 (check/write): time=1209744559.152187 ptr=0xbfa3594c size=4 pc=0xb7e047bd location=`/usr/include/boost/shared_ptr.hpp:149 (boost::shared_ptr<boost::unit_test::ut_detail::callback0_impl<boost::unit_test::ut_detail::unused> >::shared_ptr<boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()> >)' /usr/lib/libmudflap.so.0(__mf_check+0x3d) [0xb7e047bd] /home/mecklen/s5w/trunk/core/common/src/test/mudflapTest(_ZN5boost10shared_ptrINS_9unit_test9ut_detail14callback0_implINS2_6unusedEEEEC1INS2_16callback0_impl_tIS4_PFvvEEEEEPT_+0x77) [0x804ef79] /home/mecklen/s5w/trunk/core/common/src/test/mudflapTest(_ZN5boost9unit_test9callback0INS0_9ut_detail6unusedEEC1IPFvvEEET_+0x33) [0x804efe7] number of nearby objects: 0 ******* <10 more violations occur here> *** No errors detected Obviously, mudflap believes that there were invalid writes occurring in the boost libraries. I attempted to debug this by first expanding the cpp macros and removing the use of unnamed temporaries to yield: ... boost::unit_test::const_string name("mudflap"); boost::unit_test::test_case * tc = boost::unit_test::make_test_case(&mudflap_invoker, name); static boost::unit_test::ut_detail::auto_test_unit_registrar mudflap_registrar(tc, boost::unit_test::ut_detail::auto_tc_exp_fail<mudflap_id>::value); ... Running this under gdb I discover that the alleged violation appears to occur in the execution of the make_test_case(invoker, name) call, during the construction of a shared_ptr: (gdb) where #0 shared_ptr<boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()> > (this=0xbfecbddc, p=0x80d4d28) at /usr/include/boost/shared_ptr.hpp:149 #1 0x0804ed9d in callback0<void (*)()> (this=0xbfecbddc, f=0x804bf6c <mudflap_invoker>) at /usr/include/boost/test/utils/callback.hpp:111 #2 0x0804c5cd in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at mudflapTest.cpp:26 #3 0x0804c65a in global constructors keyed to _ZN5boost9unit_test44_GLOBAL__N_mudflapTest.cpp_00000000_456E4E3F13unit_test_logE () at mudflapTest.cpp:36 #4 0x0804f4f5 in __do_global_ctors_aux () #5 0x0804bcb4 in _init () #6 0x0804f499 in __libc_csu_init () #7 0xb7b853f1 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #8 0x0804bed1 in _start () ******* mudflap violation 1 (check/write): time=1209743602.806628 ptr=0xbfecbddc size=4 ... The target of the shared pointer appears normal: (gdb) p p $2 = (boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused,void (*)()> *) 0x80d4d28 (gdb) p *p $3 = (boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused,void (*)()>) { <boost::unit_test::ut_detail::callback0_impl<boost::unit_test::ut_detail::unused>> = { _vptr.callback0_impl = 0x8051970 }, members of boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused,void (*)()>: m_f = 0x804bf6c <mudflap_invoker> } The pointers within this object appear to point to valid addresses with proper data (supporting evidence omitted for brevity). (I have tried to run the unit test code without shared libraries, but my attempts at static linking have failed, so far.) In short, I cannot determine why mudflap thinks this is bogus. I believe mudflap is implemented correctly, as I've used it successfully on other non-boost test cases. Has anyone used mudflap successfully with boost? It seems a powerful tool if it could be made to work. Thanks in advance for any suggestions. -- Robert Mecklenburg