|
Boost : |
From: Juergen Hunold (hunold_at_[hidden])
Date: 2006-03-21 14:44:30
Hi !
I've been playing around with boost test and tried to run my test on my
win32 box (after a needed hardware upgrade and reinstall) using msvc
7.1.
To my surprise the tests don't run anymore. I've tracked this down to
the attached minimal testcase (using V2). I admit that my setup is
somewhat unusual, but now for the story:
I use:
- a user defined testcase ( to set up a lot of things in my tests,
omitted here.)
- our project uses BOOST_SP_USE_QUICK_ALLOCATOR to speed up shared_ptr.
(proven to boost performance by 50%)
- is multithreaded.
When running the testcase, the test runs smooth, but then the msvc
debug-runtime bombs at program exit and fires up the debugger. It
claims it has detected a memory leak.
The start of the message (see result.txt in attachment for full output):
====== BEGIN OUTPUT ======
Running 2 test cases...
user_testcase.cpp(27): error in "Tests::testFailure": failure
*** No errors detected
Detected memory leaks!
Dumping objects ->
{173} normal block at 0x00326030, 12 bytes long.
Data: <0`2 0`2 > 30 60 32 00 30 60 32 00 CD CD CD CD
The cause seems to be some static variables in the quick allocator that
are not deleted at program exit. I think this a known issue.
I've tried to disable the msvc runtime check but it failed. Using the
debugger I've traced this down to
boost/test/impl/execution_monitor.ipp and there to detect_memory_leaks
(line 623). It seems that the call to _CrtSetDbgFlag in line 629 is
somehow failing. Myself being a linux programmer my wisdom ends at this
point. This could even be a red herring and the failure might be caused
by something else.
Query: Can someone reproduce this ?
Query: Is this a bug in boost.test, boost.shared_ptr or my fault ?
Yours,
Jürgen
-- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister StraÃe 15 * hunold_at_[hidden] ! www.ive-mbh.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk