Derek Tong | 2 Sep 03:23 2009
Picon

Debugging leaked smart pointers

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

Will Vale | 2 Sep 04:11 2009

Re: Debugging leaked smart pointers

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

Emil Dotchevski | 2 Sep 04:11 2009

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

Sören Meyer-Eppler | 2 Sep 10:23 2009
Picon

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

Thaddaeus Frogley | 2 Sep 11:06 2009
Picon

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

(Continue reading)

Daniele Benegiamo | 2 Sep 11:12 2009
Picon

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

James Robertson | 2 Sep 11:23 2009

Re: 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
> 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
(Continue reading)

Boberg, Stefan | 2 Sep 11:30 2009
Picon

Re: Debugging leaked smart pointers

  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
(Continue reading)

Jon Watte | 2 Sep 20:27 2009
Picon

Re: 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

--

-- 

  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

Mat Noguchi | 2 Sep 20:45 2009

Re: Debugging leaked smart pointers

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

--

-- 
(Continue reading)


Gmane