Serialization library and memory issues
Hello Boost-users,
I'm trying to save a simple class to xml_woarchive:
class StringContainer
{
std::map
Mike Lapshin wrote:
But somewhere after it (i think it is in xml_woarchive destructor) my program falls with "Debug Assertion Failed" (I'm using VC7.1) message: HEAP[test.exe]: Invalid Address specified to RtlValidateHeap( 011B0000, 011F29E8 ) Unhandled exception at 0x77f767cd in test.exe: User breakpoint.
I couldn't swear about it, but that looks like there is a mixup between the debug run-time library and the non-debug one. It happens when you have for instance a DLL compiled in debug mode creating an object (new or malloc) that the application that has been compiled in release mode tries to de-allocate (delete or free) : it triggers those kinds of errors because the debug version and the non-debug version of the run-time use different memory allocators. So make sure your boost library and all other modules are compiled in the same (non-)debug mode. Carl
Hello Carl, Saturday, March 5, 2005, 1:54:06 PM, you wrote:
Mike Lapshin wrote:
But somewhere after it (i think it is in xml_woarchive destructor) my program falls with "Debug Assertion Failed" (I'm using VC7.1) message: HEAP[test.exe]: Invalid Address specified to RtlValidateHeap( 011B0000, 011F29E8 ) Unhandled exception at 0x77f767cd in test.exe: User breakpoint.
I couldn't swear about it, but that looks like there is a mixup between the debug run-time library and the non-debug one. It happens when you have for instance a DLL compiled in debug mode creating an object (new or malloc) that the application that has been compiled in release mode tries to de-allocate (delete or free) : it triggers those kinds of errors because the debug version and the non-debug version of the run-time use different memory allocators. So make sure your boost library and all other modules are compiled in the same (non-)debug mode.
Carl
I have solved my problem - it concluded in Ogre (Object-oriented graphic rendering engine) which I'm using now. Ogre has built-in memory manager, and he using his own allocator (so it is like a situation you described). Memory was allocated by Ogre's MM, but was deallocated by standart deallocator (why? I don't know :). I have turned off Ogre's MM and now anything works fine. -- Best regards, Mike mailto:rewinder@studiodva.com
participants (2)
-
Carl Seleborg
-
Mike Lapshin