in reply to Re^3: Tracing memory leak
in thread Tracing memory leak

That example code leaks an SV.

No, it does not. As mentioned, running this within a while(1) loop, even for several minutes (ie, millions and millions of iterations) produces 0 growth. That is unequivocally no leak.

my $count = 0; while (1) { my $test = eg(); print $count++."\n"; reportHash($test); reportScalar($test->{x}); $test = undef; }

Try this yourself. If even a single byte were leaking per iteration, this would be pretty obvious pretty quickly in a monitor.

I believe the problem you perceive is circumvented by the use of _noinc -- the value returned does not increment the reference count of the SV. Otherwise, it would be impossible to return an RV without a leak.

I will look at PL_sv_count tho.

Replies are listed 'Best First'.
Re^5: Tracing memory leak
by dave_the_m (Monsignor) on Sep 14, 2011 at 22:11 UTC
    No, it does not
    Ah, you're right. XS does an implicit sv_2mortal() of the returned RV, which is why it doesn't get leaked. I guess Inline::C must do something similar (I've never used Inline::C). The problem I perceived however wouldn't have been circumvented by the _noinc usage.

    Dave.

      The problem I perceived however wouldn't have been circumvented by the _noinc usage.

      Heh-heh -- I was going to add something like "or else you have assumed something more chimeric about the RV" since based on the empirical it seemed to me this is just a pointer value but your explication explicates (namely the implicit sv_2mortal, and the implication that the RV is a scalar tracked by perl, not just a pointer value), cool. I am very new to perl internals.

      PL_sv_count does indicate an issue but I am too beat for this evening. Thanks!