Mailing List Archive

Leak testing WAS Re: leak testing modules [was: [Encode] 3.15 Released]
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.


> On Oct 11, 2021, at 16:44, Eric Wong <> wrote:
> ?James E Keenan <> 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.