Hi Cory,
I have been able to remove the false positives from the VisualStudio
leak report by doing the procedure desribed in the following post from
the archive:
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2008-May/010839.html
http://www.mail-archive.com/osg-us...@openscenegraph.net/msg11248.html
Since then, the leak report works fine for me. If your project doesn't
use MFC at all, it won't help. But if yes, it might be helpful.
Jean-Claude
Am 10.02.2009 um 20:02 schrieb Cory Riddell:
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
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
