DESTROY handler not firing until after function return. #14032
Comments
From @FGasperCreated by @FGasperConsider the following: ============================== package Thingie; use Carp; sub DESTROY { print Carp::longmess() } package main; use strict; sub body { #When the below is commented out, $t isn't garbage-collected until return; body();When the "undef $t" is the last statement in the anonymous sub, Perl is waiting until after that scope is finished to do the GC. This runs counter to expectation since the last reference to the Thingie is removed by setting $t to undef. Moreover, this can produce errors if Thingie references a global in its DESTROY and the anonsub did a "local" on that global. The proper course would seem to be to do GC within the scope. The fact that Perl doesn't behave this way currently looks to me like a bug. Perl Info |
From @iabynOn Mon, Aug 18, 2014 at 11:59:00AM -0700, felipe@felipegasper.com wrote:
Well, the actual behaviour is that 'undef $ref' defers decrementing the When there is a 'return' statement (or any other statement following the When the undef is the last statement, the destructor is called From a technical viewpoint, the exit from a sub (pp_leavesub) can't free -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @FGasperHm. It sounds like this should be documented, then? It seems a pretty conspicuous exception to how one would normally think that this works. -FG Sent from my android device. -----Original Message----- On Mon, Aug 18, 2014 at 11:59:00AM -0700, felipe@felipegasper.com wrote:
Well, the actual behaviour is that 'undef $ref' defers decrementing the When there is a 'return' statement (or any other statement following the When the undef is the last statement, the destructor is called From a technical viewpoint, the exit from a sub (pp_leavesub) can't free -- |
From @LeontOn Mon, Aug 18, 2014 at 8:59 PM, felipe@felipegasper.com <
I can see why this happens (it mortalized the referenced SV, instead of Leon |
From @iabynOn Thu, Aug 21, 2014 at 04:58:17PM +0200, Leon Timmermans wrote:
The real fix of course is to make the stack refcounted. The sv_2mortal() -- |
From @cpansproutOn Thu Aug 21 07:59:10 2014, LeonT wrote:
undef is distinct from assignment. We can fix this case by having pp_undef pass the SV_IMMEDIATE_UNREF flag, no? (I am testing a patch right now.) Would that cause any unforeseen problems? -- Father Chrysostomos |
From @cpansproutOn Wed Aug 27 22:24:22 2014, sprout wrote:
I have gone ahead and applied my patch as 4dda930, fixing ‘undef $scalar’. -- Father Chrysostomos |
|
@cpansprout - Status changed from 'open' to 'pending release' |
From @bulk88On Wed Aug 27 22:24:22 2014, sprout wrote:
a perl object constructor (new()), that uses a global error var like errno or package var/C library equivelent, if the new call fails, and the undef is assigned to an existing object ref of the same class, triggers a DESTROY on the existing object, and wiping the global error var. So you dont know why, or its a totally different uninitialized (since the DESTROY was successful) error code, the new() failed. Changing when DESTROY is called can cause subtle bugs like that. The solution is DESTROY has to save and restore global state, but in a complex app its very difficult to know when DESTROYs will run and what classes they are from, and the code behind those classes, etc. -- |
From @FGasperThank you to everyone who has looked at this! :) On 8/28/14 8:23 AM, Father Chrysostomos via RT wrote:
|
From @khwilliamsonThanks for submitting this ticket The issue should be resolved with the release today of Perl v5.22. If you find that the problem persists, feel free to reopen this ticket -- |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
p5pRT commentedAug 18, 2014
Migrated from rt.perl.org#122556 (status was 'resolved')
Searchable as RT122556$
The text was updated successfully, but these errors were encountered: