Hi, I've been making my first forays in to using Boost on the new OS X release and have encountered some strange behaviour on 64bit machines. Testing with Boost 1.37.0 and 1.40.0 I've found that everything compiles as expected, but attempting to run any unit tests results in an error of the form: *** No errors detected test_exceptions(92517) malloc: *** error for object 0x3000100200460: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Running the test through gdb gives the following stack trace: Program received signal SIGABRT, Aborted. 0x00007fff83f98ff6 in __kill () (gdb) bt #0 0x00007fff83f98ff6 in __kill () #1 0x00007fff8403a072 in abort () #2 0x00007fff83f51095 in free () #3 0x000000010003668a in boost::unit_test::framework_impl::clear (this=0x1000698a0) at framework.ipp:133 #4 0x0000000100036788 in boost::unit_test::framework_impl::~framework_impl (this=0x1000698a0) at framework.ipp:122 #5 0x00000001000386f2 in __tcf_1 () at framework.ipp:222 #6 0x00007fff83f5d274 in __cxa_finalize () #7 0x00007fff83f5d18c in exit () #8 0x0000000100006e93 in start () at unit_test_parameters.ipp:76 This is using the vanilla GCC build that comes with the operating system (see below), default compile flags and strictly single threaded test applications. Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5646~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5646) Some Googling suggests it might be problem with a missing virtual destructor but irritatingly, none of the threads I've found reach any kind of conclusion. I was hoping the collective genius of the list would be able to inform me whether: 1. This is a known bug; I'm happy to put my debugging hat on and dive in, but not if it's already being investigated by people more qualified to do so. 2. There are any work arounds for the problem. 3. There's no problem at all; I'm being a colossal idiot and have overlooked something obvious. Thanks, vrai.