in reply to Re^6: Hard to Debug windows memory error
in thread Hard to Debug windows memory error

You are reaching the limit of my understanding. Specifically, if you execute the script:
#!/usr/bin/perl use strict; use warnings; use 5.012; use Phases; my $main_closure = bless {name => 'main_closure'}, 'Phases'; sub closure { say $main_closure; } my $external = bless {name => 'external'}, 'Phases'; END { say 'Main END' } say 'Main Last line';
with the module
package Phases; use 5.012; BEGIN { say 'Phases BEGIN' } UNITCHECK { say 'Phases UNITCHECK' } CHECK { say 'Phases CHECK' } INIT { say 'Phases INIT' } END { say 'Phases END' } my $my = bless {name => 'my'}, __PACKAGE__; my $closure = bless {name => 'closure'}, __PACKAGE__; our $our = bless {name => 'our'}, __PACKAGE__; sub closure { print $closure; } sub DESTROY { my $self = shift or say 'Nothing passed to DESTROY' and return; my $name = $self->{name} || '<undef>'; say "Phases DESTROY $name" } 1;
(borrowed heavily from Know the phases of a Perl program’s execution) outputs
Phases BEGIN Phases UNITCHECK Phases DESTROY my Phases CHECK Phases INIT Main Last line Phases DESTROY external Main END Phases END Phases DESTROY closure Phases DESTROY our Phases DESTROY main_closure

What I hear you saying is that you problem happens between "Last line" and "Main END". Are there any variables scoped at script level going out of scope? If you have suspects, you can stick them into closures to make them persist longer; that might identify which package's destructor is responsible.


#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

Replies are listed 'Best First'.
Re^8: Hard to Debug windows memory error
by jandrew (Chaplain) on Jan 04, 2016 at 17:28 UTC

    kennethk I suspect my problem is exacerbated by my using Moose for my object type. My case would be best represented by two more layers deep from the class 'Phases' where '$my', '$closure', and '$our' were built from other classes and within each of those class instances they had stored instances of each other in variables. Based on a troubleshooting suggestion provided by fishmonger I think I have traced the failing portion to the equivalent phase in your example at

    Phases DESTROY main_closure

    I now believe the root cause to be the several interlinked attributes i just outlined that are trying to unwind themselves as part of the master class unwind after they have already been cleaned up when they went out of scope before. (At the equivalent 'Phases DESTROY my' and 'Phases DESTROY closure' point in the example.) Unfortunately, an attempt to write a simple case demonstrating my suspicions did not fail. My next steps are to clean up some of the not so pretty architectural decisions I made in an effort to arrive at a lower level of complexity which I hope will either quit failing or yield a cleaner understanding of the problem. Worst case I should be able to submit a simpler question next time.