Greg Ravikovich writes:

Any workarounds?

You can try to figure out where these comes from. Not sure how it helps though. Ask MS support. Gennadiy

Mike(dev writes:

When trying to determine where memory leaks are coming from, you could try something like this...

#include int main() // try replacing this line with BOOST_AUTO_TEST_CASE_TEMPLATE { // break on memory allocation number _crtBreakAlloc = 83; // or 84, 93,94 }

Boost.Test supports this directly just pass allocation number as the value of the argument detect_memory_leaks: test_modul.exe --detect_memory_leaks=83 Unfortunately in my experience with previous version of MS runtime this doesn't actually break exactly at the same allocation we if you did not pass the parameter. It's somewhere in a vicinity though: plus/minus couple. Gennadiy

Thanks a lot guys. I'll work with the DLL runtime libraries meanwhile, The code seems to work alright using them. Greg On Mon, Jun 16, 2008 at 3:41 PM, Stephen Nuchia wrote:

The Microsoft debug libraries have some memory leaks in them. It's frustrating but I've given up on making my debug builds leak-free. If you've inspected all your DEBUG-conditional code carefully and you're sure there are no leaks in the release build, go on to another problem.

I suggest you introduce an intentional leak to make sure leak detection is working properly in your release configuration. Then write off any leaks that occur only in the debug configuration.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Thanks, Greg