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