Debugging leaked smart pointers

Derek Tong <derek.a.tong <at> gmail.com>
2009-09-02 01:23:53 GMT

Hi,
I'm currently working with smart pointers with reference counting.
Certain classes do a check (debug assert) in their shutdown routine to
make sure the reference count of the pointers they own are not higher
than they should be (i.e. 1 in these cases). Currently, a lot of
these checks are failing. I was wondering if anybody is familiar with
a straightforward, unobtrusive, approach to dealing with leaked smart
pointers? It's good to know that there's a problem, but I can't think
of an obvious way to track down to code responsible.
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: Debugging leaked smart pointers

Will Vale <will <at> secondintention.com>
2009-09-02 02:11:08 GMT

On Wed, 02 Sep 2009 13:23:53 +1200, Derek Tong <derek.a.tong <at> gmail.com>
wrote:
> make sure the reference count of the pointers they own are not higher
> than they should be (i.e. 1 in these cases).
If a given object is supposed to have the same lifetime as its owner,
which is what I understand from your description, it sounds like you don't
need to use reference counting at all?
I guess they're providing you with some debug info (detecting dangling
references) in this case though. Perhaps you could chain a linked list
through the smart pointers looking at a particular object and follow this
when you get the assert to see where the bad references are coming from.
Cheers,
Will
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: Debugging leaked smart pointers

On Tue, Sep 1, 2009 at 6:23 PM, Derek Tong<derek.a.tong <at> gmail.com> wrote:
> Hi,
>
> I'm currently working with smart pointers with reference counting.
> Certain classes do a check (debug assert) in their shutdown routine to
> make sure the reference count of the pointers they own are not higher
> than they should be (i.e. 1 in these cases). Currently, a lot of
> these checks are failing. I was wondering if anybody is familiar with
> a straightforward, unobtrusive, approach to dealing with leaked smart
> pointers? It's good to know that there's a problem, but I can't think
> of an obvious way to track down to code responsible.
You can try implementing something like
http://www.pdimov.com/cpp/shared_ptr_0x.html#cycles
Also, consider using boost::shared_ptr/weak_ptr (weak pointers are
great when cyclic references are needed.)
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: monitoring C++ memory usage?

JS Zirani schrieb:
> Sorry, it was late saturday. The exact location of the project is :
> http://supzi.wikidot.com/memtracer
Thanks a million for making the source available - the tool is
pretty much exactly what I was looking for. Your support off-list
with helping me set it up and solve dbghelp problems is also much
appreciated. I have already found some memory hogs in our
application we previsously hadn't been aware of.
Thanks!
Sören
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: monitoring C++ memory usage?

Have the object with the reference keep a list of all the pointer
objects that hold a reference to it.
Ie, anything that bumps the ref count also passes a pointer to itself
(or some other identifier) to the "AddRef" function. You can use
macros to pass in __FILE__ and __LINE__.
Example from my current project, where I had to debug what code was
inserting multple spawns into a queue:
#ifdef DEBUG_PENDING_SPAWNS
#define QueueSpawnLiveEnemy(a,b) QueueSpawnLiveEnemyFn(a,b,__FILE__,__LINE__)
void QueueSpawnLiveEnemyFn(AI::Enemy* e, CZone* zone, const char*
file, int line);
#else
void QueueSpawnLiveEnemy(AI::Enemy* e, CZone* zone);
#endif
Simple. :p
Thad
--
--
Thaddaeus Frogley
Senior Programmer, Climax Games
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: Debugging leaked smart pointers

Derek Tong wrote:
> these checks are failing. I was wondering if anybody is familiar with
> a straightforward, unobtrusive, approach to dealing with leaked smart
> pointers? It's good to know that there's a problem, but I can't think
> of an obvious way to track down to code responsible.
Well...unobtrusive in quite impossible if you don't want to debug
step-by-step the whole program.
If you are able to reproduce the problem on a small test case, you can
place breakpoints on constructors/destructors and count their calls
manually, tracking what shared object has been used. This can be a
starting point to isolate a single object instance that fails, then
concentrate your efforts only on this one.
But, as mentioned by Emil, pay *much* attention to cycles; usually most
problems are with them.
Daniele
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: Debugging leaked smart pointers

James Robertson <jamesr <at> funcom.com>
2009-09-02 09:23:26 GMT

If you're using a third party smart pointer implementation you're pretty
much at the mercy of that library.
If you have your own smart pointer class it's fairly trivial to add
debug hooks in the constructor/destructor of your classes to do pretty
much anything you want. The most basic thing you can do is retain a
global list of all active smart pointer managed objects and store the
callstacks of when they were created. You could also track when the
pointers themselves were created, but that might not be so useful. (It
really depends on your situation.)
Derek Tong wrote:
> Hi,
>
> I'm currently working with smart pointers with reference counting.
> Certain classes do a check (debug assert) in their shutdown routine to
> make sure the reference count of the pointers they own are not higher
> than they should be (i.e. 1 in these cases). Currently, a lot of
> these checks are failing. I was wondering if anybody is familiar with
> a straightforward, unobtrusive, approach to dealing with leaked smart
> pointers? It's good to know that there's a problem, but I can't think
> of an obvious way to track down to code responsible.
> _______________________________________________
> Sweng-Gamedev mailing list
> Sweng-Gamedev <at> lists.midnightryder.com
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>
_______________________________________________
Sweng-Gamedev mailing list

Re: Debugging leaked smart pointers

Boberg, Stefan <Stefan.Boberg <at> dice.se>
2009-09-02 09:30:24 GMT

This problem is almost the same as memory tracking. If you can instrument your addRef/release calls you can
use the same tools more or less. You'll end up with a lot of trace events though :)
/Stefan
-----Original Message-----
From: sweng-gamedev-bounces <at> lists.midnightryder.com
[mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of James Robertson
Sent: 02 September 2009 11:23
To: sweng-gamedev <at> midnightryder.com
Subject: Re: [Sweng-Gamedev] Debugging leaked smart pointers
If you're using a third party smart pointer implementation you're pretty
much at the mercy of that library.
If you have your own smart pointer class it's fairly trivial to add
debug hooks in the constructor/destructor of your classes to do pretty
much anything you want. The most basic thing you can do is retain a
global list of all active smart pointer managed objects and store the
callstacks of when they were created. You could also track when the
pointers themselves were created, but that might not be so useful. (It
really depends on your situation.)
Derek Tong wrote:
> Hi,
>
> I'm currently working with smart pointers with reference counting.
> Certain classes do a check (debug assert) in their shutdown routine to
> make sure the reference count of the pointers they own are not higher
> than they should be (i.e. 1 in these cases). Currently, a lot of

Re: Debugging leaked smart pointers

Jon Watte <jwatte <at> gmail.com>
2009-09-02 18:27:23 GMT

Derek Tong wrote:
> I'm currently working with smart pointers with reference counting.
>
>
The "nuclear option" is to require an owner to be included whenever a
reference count is acquired. This requires massive code re-writing,
though. References to owners would have to be weak (in the sense that
the owner clears out the references when the pointer to the child is
changed).
Once you have that, you can implement a fully clickable object
exploration GUI that allows you to back/forward track any data
structure, if you want.
Sincerely,
jw
--
--
Revenge is the most pointless and damaging of human desires.
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com

Re: Debugging leaked smart pointers

Mat Noguchi <matthewn <at> bungie.com>
2009-09-02 18:45:23 GMT

I agree. Reference tracking is way more effective for debugging than reference counting.
MSN
-----Original Message-----
From: sweng-gamedev-bounces <at> lists.midnightryder.com
[mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Jon Watte
Sent: Wednesday, September 02, 2009 11:27 AM
To: sweng-gamedev <at> midnightryder.com
Subject: Re: [Sweng-Gamedev] Debugging leaked smart pointers
Derek Tong wrote:
> I'm currently working with smart pointers with reference counting.
>
>
The "nuclear option" is to require an owner to be included whenever a
reference count is acquired. This requires massive code re-writing,
though. References to owners would have to be weak (in the sense that
the owner clears out the references when the pointer to the child is
changed).
Once you have that, you can implement a fully clickable object
exploration GUI that allows you to back/forward track any data
structure, if you want.
Sincerely,
jw
--
--