On Wed, Feb 23, 2005 at 02:18:17PM -0500, Steven N. Hirsch wrote: > On Wed, 23 Feb 2005, William Ahern wrote: > > > Has anyone run into the issue of av_undef not doing what is advertized in > > perlguts, namely freeing the object? I realize the solution is just to > > decrement the ref count like anything else, but in uncovering my memory leak > > I found a lot of other people were bit by this. Has the man page ever been > > updated? > > I have spent an enormous amount of time chasing memory leaks in my XS > code, but I'm not sure it's the same mechanism. One application in > particular parses a text file using flex/bison and sequentially builds > complex perl data structures to pass into registered perl callbacks. > > For reasons I've never been able to figure out, this memory never gets > freed; even though no references are taken on the perl side and all > structures are recursively undefined in C.
Do you mean undefined as in hv_undef, av_undef, etc? Have you tried decrementing the ref count with SvREFCNT_dec also, or instead of? If I understand the issue with av_undef properly, av_undef does *not* free and does *not* seem to decrement the ref count of the object. It probably removes (and I hope drops the ref counts of) it's elements, but certainly not the actual array itself. Dropping the ref count with SvREFCNT_dec releases all elements _and_ frees the array object. > Documentation claims that the storage is freed when flow of control > "leaves the current context", but I wonder what that means in concrete > terms. Does a return from an XS call count as "leaving the context"? In my tests objects were freed when I redefined their identifier or the block closed. Simple returning from an XS call did not by itself cause the garbage collector to free them.
