Front page | perl.perl5.porters |
Postings from October 2021
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