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
