Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

hv_store and memory leaking/ref counts

by patcat88 (Deacon)
on Apr 03, 2011 at 21:51 UTC ( #897242=perlquestion: print w/ replies, xml ) Need Help??
patcat88 has asked for the wisdom of the Perl Monks concerning the following question:

I am tracking down a memory leak in XS code I wrote. I repeatedly do "hv_store(self, "hashslice", sizeof("hashslice")-1, newRV_inc(someSV), 0);" on the hash. someSV is the same pointer every time the hv_store runs. I see the refcnt of sameSV going up and up. hv_store may or may not be the source of my memory leak, (I have a few other ideas) but I'm confused on how to use hv_store, so I want to be dead certain I'm using it correctly.

What happens if the hash slice has an existing SV in the slice when you run hv_store on that hash slice? Will hv_store run SvREFCNT_dec on it? or will the existing SV appear in the return of hv_store (as an SV **)? or do you have to explicitly run hv_fetch and then possibly hv_delete before you can safely do hv_store?

The documentation doesn't say anything. In perlguts it just says hv_store returns an SV **. The examples of hv_store never capture the returned SV ** or do anything with it. In perlxstut] hv_store is used on a virgin HV, so no SV can be in that slice when we call hv_store. In perlapi it says "The return value will be NULL if the operation failed or if the value did not need to be actually stored within the hash (as in the case of tied hashes). Otherwise it can be dereferenced to get the original SV* ." and it talks about the refcounts for the SV your going store at the hash slice. Not about the refcounts of what used to be/currently is in the hash slice.

Comment on hv_store and memory leaking/ref counts
Re: hv_store and memory leaking/ref counts
by ikegami (Pope) on Apr 03, 2011 at 23:44 UTC

    I repeatedly do "hv_store(self, "hashslice", sizeof("hashslice")-1, newRV_inc(someSV), 0);"

    Isn't sizeof("hashslice")-1 one less than the size of a pointer? You want strlen("hashslice") (no -1).

    Will hv_store run SvREFCNT_dec on it?

    Yes.

    I see the refcnt of sameSV going up and up.

    If you keep assigning to the same key, it'll go up when you create the reference, then go back down when the previous reference you created gets freed as hv_store overwrites the old value. Unless you copied the old reference.

    my $x; for (1..3) { $h{hashslice} = \$x; print(Internals::SvREFCNT($x), "\n"); }
    2 2 2
    my $x; my @a; for (1..3) { $h{hashslice} = \$x; print(Internals::SvREFCNT($x), "\n"); push @a, $h{hashslice}; }
    2 3 4

    The examples of hv_store never capture the returned SV ** or do anything with

    The docs say "Note that the caller is responsible for suitably incrementing the reference count of val before the call, and decrementing it if the function returned NULL." so your code should look like:

    if (!(sv = hv_store(...))) { SvREFCNT_dec(sv); ... }
Re: hv_store and memory leaking/ref counts
by sundialsvc4 (Abbot) on Apr 04, 2011 at 17:38 UTC

    Perhaps you can make good use of Test::Memory::Cycle (and Devel::Cycle).

    Can you reduce this to an isolated, stand-alone test case, using the minimum possible amount of code, that demonstrates the problem?   When tracking down memory leaks and reference-count problems, perhaps the problem is not strictly and totally in the code that you are now looking at.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://897242]
Approved by GrandFather
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (8)
As of 2014-12-19 12:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (81 votes), past polls