Boost.Test claims Qt leaks memory

Hi,
I'd appreciate some advice using the Boost unit testing library with
Qt classes.
I'm using MSVC 8.0 on windows XP.
It appears that simply creating and destroying a QObject allocates some
static datastructures which are reported as a memory leak by Boost.Test.
I'd like to somehow suppress this "static leak" so that Boost.Test may
find real leaks in my code. Consider the following test program
#define BOOST_AUTO_TEST_MAIN
#include

Hi,
I'd appreciate some advice using the Boost unit testing library with Qt classes.
I'm using MSVC 8.0 on windows XP.
It appears that simply creating and destroying a QObject allocates some static datastructures which are reported as a memory leak by Boost.Test. I'd like to somehow suppress this "static leak" so that Boost.Test may find real leaks in my code. Consider the following test program
#define BOOST_AUTO_TEST_MAIN #include
#include BOOST_AUTO_TEST_CASE( example ) { BOOST_CHECK_EQUAL( 1, 1 ); QObject obj; }
It builds and runs fine, except that memory leaks are detected.
My first line of attack is to clean up after Qt somehow. (c.f. http://lists.trolltech.com/qt-interest/2007-08/thread00997-0.html)
Hello, The hack there doesn't work, because the memory leak detection capability is not implemented in Boost.Test itself, it is a feature of the MS VC++ Debug runtime libraries (MSVCRxxD.dll), so the leak detector starts before that application is running. I think, to solve the issue you have to hack Qt itself, so that the memory is really free'd at program exit time. You can achive this by calling std::atexit( cbFunc ) once after allocating the static pointer. This way you can add a (static) user callback function that is called from runtime library at exit time. In that function you can release the memory from the pointer. Uwe. *** The information in this e-mail is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this e-mail in error please notify the sender by return e-mail delete this e-mail and refrain from any disclosure or action based on the information. ***

On Tue, Sep 04, 2007 at 09:02:11AM +0200, Uwe Schuster wrote:
My first line of attack is to clean up after Qt somehow. (c.f. http://lists.trolltech.com/qt-interest/2007-08/thread00997-0.html)
Hello,
The hack there doesn't work, because the memory leak detection capability is not implemented in Boost.Test itself, it is a feature of the MS VC++ Debug runtime libraries (MSVCRxxD.dll), so the leak detector starts before that application is running.
Right. I dug a bit further into it and managed to make the "ignore the first QObject creation" hack work as follows. // Have Boost.Test ignore the memory leak from Qt static data. class IgnoreQtStaticData { public: IgnoreQtStaticData() { #if BOOST_MSVC // Disable all heap debugging, allocate and destroy a QObject, // then re-enable heap debugging. int flags = _CrtSetDbgFlag( 0 ); allocate(); _CrtSetDbgFlag( flags ); #endif } static void allocate() { QObject obj; }; }; static IgnoreQtStaticData ignoreQtStaticData; Regards, -Steve
participants (2)
-
Steve M. Robbins
-
Uwe Schuster