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/
