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/
