in reply to Re^4: Win32 - Memory can not be "read"
in thread Win32 - Memory can not be "read"

I'd stick a trace statement (probably to a separate file), either side of that for loop.

MAKE_CLASSES: printf $temporaryLog "%s : Enter loop %d keys ...", scalar localtime() +, scalar keys %c; foreach my $subclass ( sort { length $a <=> length $b } keys %c ) { ... } printf $temporaryLog "exited\n";

And run that on whichever machine is giving the greatest frequency of failures. At worst, it will allow you to eliminate a red-herring. At best, it just might show you something that will take you a step closer.

In a similar vein, if you have a test machine that is demonstrating the failure regularly, or a production machine that you can sign off on having run really slowly for a while, then get Devel::Trace and use it to see where the failure is occuring.

perl -d:Trace yourscript.pl 2>yourlog

The problem with that is the logfile will be overwritten by subsequent successful runs, If you use 2>>log you might fill your disc, and you'd have a mountain of log to search through.

So, add a couple of lines to the script:

BEGIN{ close STDERR; open STDERR, '>', "$$.log" } END{ close STDERR; unlink "$$.log"; }

That will direct the trace output to a separate file for each run and, if the program completes successfully, delete that file and prevent your disk from filling up. Any runs which terminate abnormally should leave their log files behind which should give you a pretty clear picture of where the script is terminating.

Good luck!


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.