HI Alan, On 6/11/06, Alan Harris <[EMAIL PROTECTED]> wrote:
I think the more important issue is memory cleanup in OSG which is not happening. Static variables will remain around until the DLL is unloaded, and therefore additions to std:map variables (or similar) when a model is loaded will result in growing memory use, unless these variables are cleaned up when the model is deleted.
The OSG has static variables, but these shouldn't be the cause of problematic memory consumption, once allocated they should just sit in memory and not be reallocated multiple times - kinda the point of statics. In the case of ApplicationUsage I can't image it every causing a problem, as its just constructed once and populated with application options once, each new model load shouldn't increase its size. Some of the static data associated with manage deleted OpenGL objects could be more of an issue, and there are specific handles for helping clean the OpenGL objects up. These static arrays have to exist as you can delete a scene graph in any thread, and once which is likely not to have the relevant graphics thread current and therefore unable to immediately call OpenGL to free them. These static arrays therefore get populated and need to be flushed from the threads with the graphics contexts. SceneView has support for this. Have a look at the osgsimplepager, as it has loop for creating multiple windows and has explict cleaning up code. However, if you're not closing an opening windows then SceneView will do this flush on each normal frame. Robert.
I do not know OSG to your level, and I may be wrong, but I was suggesting that this may be the reason for the memory growth behaviour that others have commented on in the last few weeks. Cheers Alan Gordon Tomlinson wrote: >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! > > > _______________________________________________ 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/
