Front page | perl.qa |
Postings from August 2022
Re: Having memory leak issues with perl-c
Thread Previous
|
Thread Next
From:
demerphq
Date:
August 4, 2022 19:11
Subject:
Re: Having memory leak issues with perl-c
Message ID:
CANgJU+W95nxb9HB_EEXUo3KDYqx-1xe14TZmJG_v-RBD=evZpw@mail.gmail.com
On Thu, 4 Aug 2022 at 17:04, Mark Murawski <markm-lists@intellasoft.net>
wrote:
> 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.
>
>
You did not respond to this comment ^^
>
>
>>
>> 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?
>
No, you shouldn't do anything after creating the hash that might die until
you have arranged for hv to be freed. Storing into the hash might die.
>
> 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.
>
YW.
>
> 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?
>
Well I dont know for sure as I dont know the latest state of your code. But
my thinking is that you asked for $main::_FN which is in the package table,
so perl should clean it up. But I dont understand why you are using
save_item(FNsv).
> I still have a leak here, using the above code.
>
Probably I would be able to help you better if you posted the latest state
of your code, with sv_dump() calls liberally sprinkled through the code,
and post the output as well.
>
> Also... i get a crash when I use sv_clear(FNsv); right away like this.
>
And what does FNsv look like immediately before you call sv_clear()?
> 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.
>
Can you please show a reduced version of the code? And explain why you are
doing save_item(FNsv)? And provide some of the output of sv_dump()?
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next