>From my previous post on this subject. ( you can search the mail archives also google with find and search the OSG mail archives)
There is a known issue/BUG with MFC, were MFC makes a call to _CrtDumpMemoryLeaks() in the destructor of the _AFX_DEBUG_STATE, followed by _CrtSetDbgFlag() which sets it to ~_CRTDBG_LEAK_CHECK_DF (therefor disabling memory leak test at *true* program exit) This destructor is called at exit (i.e. atexit()), but before statics residing in dlls and others are destroyed, resulting in many false memory leaks are reported As to fix any real memory leaks, you have the source ... also you can do a google to see how others have gotten around this issue to get at any real leaks. The MFC memory leak will not go away as MicroSoft have no reason to fixe it( it been there for many years) as MFC is a depricated API as far as they are conscerned Best Regards Gordon __________________________________________________________ Gordon Tomlinson Email : [EMAIL PROTECTED] YIM/AIM : Gordon3dBrit MSN IM : [EMAIL PROTECTED] Website : www.3dscenegraph.com __________________________________________________________ "Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival" - Master Tambo Tetsura -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Harris Sent: Saturday, June 10, 2006 7:18 AM To: osg users Subject: [osg-users] Memory use Hi A number of people have raised the issue of memory problems when using OSG with MFC. There have also been issues of memory leakage with other GUI's and indications of growing memory use as models are opened and closed. I have noticed this happening and have tried to dig a little further into it. If a debug version of the OSG library is used in MFC then a multitude of memory leaks are reported on exiting from the application. As far as I can tell this is because the memory leaks are detected before the DLL is completely unloaded. I expect this is because the DLL is hanging around on another thread. I have tried unloading the DLL before exit (with FreeLibrary()) without success - I am probably doing something wrong, I do not have enough expertise in this area. Experimentation with a simple DLL based on osg::ApplicationUsage appears to confirm this behaviour. ApplicationUsage is instantiated statically within the DLL and therefore there will always be some residual memory usage even if no strings or map have been specified. There is nothing basically wrong with the memory allocation within ApplicationUsage - the variables all release their memory on destruction. So the order of memory leak detection and DLL destruction appears to be the problem - not a problem with OSG. However, it also raises a supplementary issue. Within ApplicationUsage there is no cleaning up of the memory allocated to the strings and the map. Therefore, with repeated use the memory use grows and the memory leaks reported on eventual exit could be large. ApplicationUsage probably has limited use and this may not apply in this case. I do not know enough about OSG yet, but I suspect there are other areas where this static allocation within the DLL is occuring. This could easily account for the growth in memory use as models are opened and closed, that I and others have noted. It appears therefore that some form of cleanup is needed. I added the following to my test AUsage class (my simple version of ApplicationUsage): void deleteContents() { // UsageMap variables if (!_environmentalVariables.empty()) _environmentalVariables.clear(); // string variables // in MSVS this does not clear the memory - just sets the first char to 0! if (!_applicationName.empty()) _applicationName.clear(); } Remember there will still be some residual memory usage even if no strings or map have been specified. My version of the proxy then becomes: class AUsageProxy { public: AUsageProxy() { AUsage::instance()->deleteContents(); } /** register an explanation of commandline/evironmentalvaraible/keyboard mouse usage.*/ AUsageProxy(AUsage::Type type,const std::string& option,const std::string& explanation) { AUsage::instance()->addEnvironmentalVariable(option,explanation); } void deleteContents() { AUsage::instance()->deleteContents(); } ~AUsageProxy() { AUsage::instance()->deleteContents(); } }; This gives a number of routes for cleaning up memory allocation. If AUsageProxy is instantiated within a temporary class then its destruction will automatically delete the contents. Otherwise a call such as: AUsageProxy cleanup; will perform the cleanup. If nothing else it reduces the reported "memory leaks" to the residual amount. Assuming that there are other places where static memory use grows as models are opened and closed then a means of cleaning them up centrally needs to be provided. I hope this makes sense and, more importantly, is correct! -- Regards Alan Harris ReSoft Ltd 7 Church Lane Flitton BEDFORD, MK45 5EL, UK Tel: +44 (0) 1525 862616 Email: [EMAIL PROTECTED] Web: www.resoft.co.uk _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
