Can anybody recommend a Windows-based memory tracking tool? I have
BoundsChecker but it thinks this is a leak:
Foo* p = new Foo;
osg::ref_ptr<Foo> pFoo = p;
I wrestled with Purify for a few days but even with Rational's help I
could not get it to work with our application.
Cory
Robert Osfield wrote:
Hi Cory,
This is a bug in the memory tracking tool you have. Perhaps looking
for another more robust tool would be a better use of your time.
If you absolutely do want to manually force clean up then you can
reset the singletons by setting them to 0.
For onces that return a ref_ptr<>& you can do:
osgDB::DatabasePager::prototype() = 0;
The osgDB::Registry is quite old and misses the above trick of using a
ref_ptr<> reference, so has a rather hacky way to delete the signleton
(note, the declaration is static Registry* instance(bool erase =
false);
osgDB::Registry::instance(true);
You'll need to take about destruction order.
Robert.
On Tue, Feb 10, 2009 at 6:34 PM, Cory Riddell <c...@codeware.com> wrote:
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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
|
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
