I (and others) have asked about apparent memory leaks reported in Visual
Studio when an OSG app exits. The leak dump looks like this:
Detected memory leaks!
Dumping objects ->
{29751} normal block at 0x0293C970, 36 bytes long.
Data: <, E > 2C 0B 45 10 00 00 00 00 01 00 00 00 01 CD CD CD
{29738} normal block at 0x0293C740, 500 bytes long.
Data: <X)A ` @> 58 29 41 10 00 00 00 00 01 00 00 00 60 93 0B 40
{29727} normal block at 0x028DA8A0, 84 bytes long.
Data: < 1D 0 %i> C8 31 44 10 00 00 00 00 01 00 00 00 30 85 25 69
...
I spent my morning tracking down exactly what is going on here and I
thought I would post my findings in case it's helpful to others.
It took a bit of futzing around, but I finally identified one of the
leaking objects as a DatabasePager instance. A DatabasePager may be
constructed via a prototype which is static:
osg::ref_ptr<DatabasePager>& DatabasePager::prototype()
{
static osg::ref_ptr<DatabasePager> s_DatabasePager = new
DatabasePager;
return s_DatabasePager;
}
The static instance doesn't go out of scope until the application is
being torn down (atexit) and the memory dump happens before that begins.
Is anybody interested in discussing how to manage these singleton
objects differently so they are explicitly deleted to avoid the
(incorrect) memory leak report? I totally understand that every
destructor that should be called is eventually called. However, for
those of us stuck developing for Windows, it would be useful to change
the behavior to avoid the false positives.
-cr
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
