develooper Front page | perl.perl5.porters | Postings from October 2021

Leak testing WAS Re: leak testing modules [was: [Encode] 3.15Released]

Thread Previous | Thread Next
From:
Felipe Gasper
Date:
October 11, 2021 23:01
Subject:
Leak testing WAS Re: leak testing modules [was: [Encode] 3.15Released]
Message ID:
EDF09B7B-DD86-4ADB-BC21-29E687277063@felipegasper.com
On a much simpler level, I often make modules warn if they DESTROY at global destruct time and the PID hasn’t changed. Destruct-time DESTROY doesn’t always mean a leak, but it’s easy to clean up the non-leak uses at END time instead.

-F

> On Oct 11, 2021, at 16:44, Eric Wong <p5p@yhbt.net> wrote:
> 
> James E Keenan <jkeenan@pobox.com> wrote:
>>> On 10/8/21 11:50 AM, Dan Kogai wrote:
>>> Porters,
>>> 
>>> My apology for releasing 3.14 prematurely and releasing 3.15 to resolve it.  In a way, this is what Encode 3.13 was supposed to be.
>> 
>> Dan, just now I synched Encode 3.15 into blead ( cf927cc ).  Can you double
>> check that this distribution now appears in blead as it should be for our
>> next development release on October 20 2021?
> 
> I'm not Dan, but Encode.xs being blob 3416df70fa9fd640 looks right to me :>
> 
> Does anybody here have suggestions on how to go about adding
> leak tests to packages like Encode?
> 
> I see XS::APItest exists and exposes PL_sv_count; but I guess
> it's only for Perl internals and not for stuff imported from CPAN?
> 
> It'd be nice to have regression testing guard against
> introducing leaks for other core modules, too.  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