Re: [Libfoundation-users] Debugging Retain Cycles

[Sven C. K. <sc...@sn...>]

Hi Helge, 

On Mon, Aug 20, 2001 at 10:40:36AM +0200, Helge Hess wrote:
> are you searching for RC leaks *inside* of lF or in code using lF ? If
> you look for leaks outside of lF you might consider using the GCObject
> class instead of NSObject, since it provides a simple, RC based, garbage
> collector (which tracks cycles ...).

Thanks for the hint to GCObject!
No, I am not searching leaks inside the lF.  I did once use purify to
search for memory leaks/access faults, and they all turned out to be
based on my own fault--so lF seems to be pretty leak-less. (Actually,
purify reported some unintialized memory reads, but they did not seem to
hurt.)

> Another good way to find memory leaks is Boehm GC in leak mode, but it's
> now long ago that I used that feature. I think dmalloc also supports a
> similiar tracing feature.

Concerning Boehm GC, I am somewhat suspicious regarding conservative GC,
since it doesn't use typed memory, and so it might not see all leaks that
are there--but I did not read yet much in the documentation of Boehm GC.
Another thing is that it seems to require a rebuilt of libobjc, what is
expensive.  

> > My next idea would be to somehow wrap NSObject's retain (either on the
> > source code or on the linker level), and to log the information I
> > need.  But before I do this, I'd just like to know whether there are
> > better ways.
> 
> I doubt that you can get the info you want by overiding -retain/-release
> ! Methods don't know where they are called from.

One could read the return address from the stack, and translate it
afterwards via binutils's addr2line program, but that's very evil!

Regards,

Sven Koehler