develooper Front page | perl.qa | Postings from August 2022

Re: Having memory leak issues with perl-c

Thread Previous | Thread Next
From:
Mark Murawski
Date:
August 4, 2022 15:04
Subject:
Re: Having memory leak issues with perl-c
Message ID:
0cca025e-9365-69bb-ba63-eaa8ccf0cd16@intellasoft.net
On 8/4/22 02:50, demerphq wrote:
> On Thu, 4 Aug 2022 at 01:58, Mark Murawski 
> <markm-lists@intellasoft.net> wrote:
>
>     I'm still not getting something... if I want to fix the code-as-is
>     and do this:
>
>         FNsv = get_sv("main::_FN", GV_ADD);
>         if (!FNsv)
>             ereport(ERROR,
>     (errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
>                      errmsg("couldn't fetch $_FN")));
>
>         save_item(FNsv);            /* local $_FN */
>
>
> I dont get the sequence here. You take the old value of $main::_FN and 
> then you localize it after you fetch it? That seems weird.
>
>
>         hv = newHV(); // create new hash
>         hv_store_string(hv, "name", cstr2sv(desc->proname));
>
>
> Really you shouldnt do this until you have safely managed the 
> refcounts of all your newly created objects so that if this die's 
> nothing leaks.

I take this to mean , setting up FNsv first, and then allocating hv?  
But in this case we seem to have a chicken/egg problem?  How can you set 
up FNsv to point to hv without first setting up hv?


>     WARNING:  Attempt to free unreferenced scalar: SV 0x55d5b1cf6480,
>     Perl interpreter: 0x55d5b17226c0
>
>
> Why are you decrementing hv? You dont own hv anymore, it's owned by 
> svFN and after the sv_setsv() call also FNsv. You shouldnt mess with 
> its refcount anymore.

The ownership aspect is making more sense now, thanks for clarifying.

> Obviously in perl we can write:
>
> my %hash;
> $main::_FN= \%hash;
>
> And in XS we can do the same thing. Unfortunately there isn't a 
> utility sub to do this currently, it has been on my TODO list to add 
> one for some time but lack of round tuits and all that.
>
> You want code something like this:
>
> sv_clear(FNsv); /* undef the sv */
> sv_upgrade(FNsv,SVt_RV);
> SvRV_set(FNsv, (SV*)hv);
> SvROK_on(FNsv);
>
> Again, make liberal use of sv_dump() it is the XS version of 
> Data::Dumper more or less.

I have been playing with sv_dump()... At the end of this flow, the 
refcount to FNsv is 1 and should get automatically cleaned up by Perl, 
right?  I still have a leak here, using the above code.

Also... i get a crash when I use sv_clear(FNsv); right away like this.
If I take it out, the code seems to all run correctly, but I have a leak 
and the hash or the hash reference is not being cleaned up.


Thanks.
Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About