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.
-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.