Re: [Boost-bugs] [Boost C++ Libraries] #2889: Unit Test framework does things that OS X's malloc dislikes

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #2889: Unit Test framework does things that OS X's malloc dislikes
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2009-09-23 20:28:53


#2889: Unit Test framework does things that OS X's malloc dislikes
-------------------------------------+--------------------------------------
 Reporter: akim.demaille@… | Owner: rogeeff
     Type: Bugs | Status: new
Milestone: Boost 1.39.0 | Component: test
  Version: Boost 1.38.0 | Severity: Regression
 Keywords: osx |
-------------------------------------+--------------------------------------
Changes (by akim.demaille@…):

  * severity: Problem => Regression

Comment:

 It is worth noting that Valgrind has the same opinion: something invalid
 is done. This is Mac OS X 10.5, boost 1.39:

 {{{
 ==71960== Memcheck, a memory error detector
 ==71960== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
 ==71960== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright
 info
 ==71960== Command: ./cli
 ==71960==
 --71960-- ./cli:
 --71960-- dSYM directory is missing; consider using --dsymutil=yes
 Running 1 test case...

 *** No errors detected
 ==71960== Invalid read of size 4
 ==71960== at 0x7969F: __tcf_1 (in /opt/local/lib
 /libboost_unit_test_framework-mt.dylib)
 ==71960== by 0x21FDBB: __cxa_finalize (in /usr/lib/libSystem.B.dylib)
 ==71960== by 0x21FCAF: exit (in /usr/lib/libSystem.B.dylib)
 ==71960== by 0x198A: (below main) (in ./cli)
 ==71960== Address 0x40d684 is 20 bytes inside a block of size 24 free'd
 ==71960== at 0x13B1A: operator delete(void*) (vg_replace_malloc.c:346)
 ==71960== by 0x7D65E: std::_Rb_tree<unsigned long, std::pair<unsigned
 long const, boost::unit_test::test_unit*>,
 std::_Select1st<std::pair<unsigned long const,
 boost::unit_test::test_unit*> >, std::less<unsigned long>,
 std::allocator<std::pair<unsigned long const,
 boost::unit_test::test_unit*> >
>::erase(std::_Rb_tree_iterator<std::pair<unsigned long const,
 boost::unit_test::test_unit*> >, std::_Rb_tree_iterator<std::pair<unsigned
 long const, boost::unit_test::test_unit*> >) (in /opt/local/lib
 /libboost_unit_test_framework-mt.dylib)
 ==71960== by 0x7D70E: std::_Rb_tree<unsigned long, std::pair<unsigned
 long const, boost::unit_test::test_unit*>,
 std::_Select1st<std::pair<unsigned long const,
 boost::unit_test::test_unit*> >, std::less<unsigned long>,
 std::allocator<std::pair<unsigned long const,
 boost::unit_test::test_unit*> > >::erase(unsigned long const&) (in
 /opt/local/lib/libboost_unit_test_framework-mt.dylib)
 ==71960== by 0x7A0E3:
 boost::unit_test::framework::deregister_test_unit(boost::unit_test::test_unit*)
 (in /opt/local/lib/libboost_unit_test_framework-mt.dylib)
 ==71960== by 0x95219: boost::unit_test::test_unit::~test_unit() (in
 /opt/local/lib/libboost_unit_test_framework-mt.dylib)
 ==71960== by 0x7969B: __tcf_1 (in /opt/local/lib
 /libboost_unit_test_framework-mt.dylib)
 ==71960== by 0x21FDBB: __cxa_finalize (in /usr/lib/libSystem.B.dylib)
 ==71960== by 0x21FCAF: exit (in /usr/lib/libSystem.B.dylib)
 ==71960== by 0x198A: (below main) (in ./cli)
 ==71960==
 ==71960==
 ==71960== HEAP SUMMARY:
 ==71960== in use at exit: 4,484 bytes in 11 blocks
 ==71960== total heap usage: 61 allocs, 50 frees, 531,099 bytes allocated
 ==71960==
 ==71960== LEAK SUMMARY:
 ==71960== definitely lost: 0 bytes in 0 blocks
 ==71960== indirectly lost: 0 bytes in 0 blocks
 ==71960== possibly lost: 0 bytes in 0 blocks
 ==71960== still reachable: 4,104 bytes in 2 blocks
 ==71960== suppressed: 380 bytes in 9 blocks
 ==71960== Rerun with --leak-check=full to see details of leaked memory
 ==71960==
 ==71960== For counts of detected and suppressed errors, rerun with: -v
 ==71960== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
 }}}


 The problem is now even more acute on Snow Leopard (10.6), with Boost.Test
 1.40. Using the same file, and compiled with Apple's GCC-4.2:

 {{{
 $ ./cli
 Running 1 test case...

 *** No errors detected
 cli(38688) malloc: *** error for object 0x30001002034f0: pointer being
 freed was not allocated
 *** set a breakpoint in malloc_error_break to debug
 zsh: abort ./cli
 }}}

 i.e., the test '''fails'''. My whole test suite is red, not a single test
 passes, because of this problem. If you are still hoping this is some
 compiler error, I'm afraid to say that GCC 4.5 features the exact same
 behavior.

 The stack trace is beautifully useless. "Of course" it is some destructor
 that is doing something wrong. But which one is an exercise left to the
 reader.

 {{{
 #0 0x00007fff8605dbe1 in malloc_error_break ()
 #1 0x00007fff85f87203 in free ()
 #2 0x0000000100010d62 in __tcf_1 ()
 #3 0x00007fff85f933f4 in __cxa_finalize ()
 #4 0x00007fff85f9330c in exit ()
 #5 0x0000000100001487 in start ()
 }}}


 Changing to regression, as it's getting worse.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/2889#comment:3>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:01 UTC