Thanks Gordon
I agree with the points you make about MFC as I pointed out.
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.
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/
