On Wed, 23 Feb 2005, William Ahern wrote:
> 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?
Sorry, I mispoke. I'm decrementing ref count using the appropriate macro.
> 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.
This, I think, is the crux of my problem. I suppose I could contrive to
always wrap the XS call in a do-nothing set of braces. However, I'm
curious as to whether a better approach would be to establish a new perl
calling context on entry:
xs_entry:
dSP;
ENTER;
... do things here
LEAVE;
leave XS code..
This should trigger garbage collection before control leaves C. I'm not
sure whether the sequence and/or syntax is correct. Can anyone comment?
Steve
