perl58.dll!Perl_newFOROP(      ??? Doing a for loop ???
    interpreter * my_perl=0x00225ffc, 
    long flags=0, 
    char *label=0x01867624, 
    unsigned long forline=32,  ??? Does this mean line 32 of the sourc
+e file ???
    op * sv=0x00000000, 
    op * expr=0x018956f4, 
    op * block=0x018955dc, 
    op * cont=0x00000000
) Line 3877 + 0x9    C 
    
perl58.dll!Perl_yyparse(                ??? parsing ???
    interpreter * my_perl=0x0173adfc
)  Line 257 + 0x18    C

perl58.dll!S_doeval(                    ??? Evaling the code ???
    interpreter * my_perl=0x01890668, 
    int gimme=0, 
    op * * startop=0x00000000, 
    cv * outside=0x00000000, 
    unsigned long seq=2630
)  Line 2817 + 0x6    C

perl58.dll!Perl_pp_require(              ??? Loading a module ???
    interpreter * my_perl=0x0167a5ac
)  Line 3314 + 0x3a  C

perl58.dll!Perl_runops_standard(
    interpreter * my_perl=0x00225ffc
)  Line 23 + 0xc    C
[download]

The stack trace suggests that the problem occurs when you are processing a for loop. And the assember instruction where the trap is occuring is the rep move ... which supports that.

From that, I'd hazard a wild guess that you have a for loop that running off the end of the data it is copying, and from the stack trace, it looks like that for loop is located in a module--maybe at line 32 of the file?

Like I say, that's mostly guesswork, but if your script doesn't have too many dependancies it might be worth looking at line 32 of each of them and seeing if there is a for loop there, before dismissing this completely :)

Wow...it's amazing what we learn on Perlmonks! :)

Thanks, I took your advice, and did some digging. Will you be too surprised to learn I found a for() loop on line 32 of a module?

It's not our module though...it's Exception::Class. Here's the beginning of the code in that module (ending at the for() statement on line 32):

package Exception::Class;

use 5.005;

use strict;
use vars qw($VERSION $BASE_EXC_CLASS %CLASSES);

BEGIN { $BASE_EXC_CLASS ||= 'Exception::Class::Base'; }

$VERSION = '1.19';

sub import
{
    my $class = shift;

    local $Exception::Class::Caller = caller();

    my %c;

    my %needs_parent;
    while (my $subclass = shift)
    {
   my $def = ref $_[0] ? shift : {};
   $def->{isa} = $def->{isa} ? ( ref $def->{isa} ? $def->{isa} : [$def
+->{isa}] ) : [];

        $c{$subclass} = $def;
    }

    # We need to sort by length because if we check for keys in the
    # Foo::Bar:: stash, this creates a "Bar::" key in the Foo:: stash!
 MAKE_CLASSES:
    foreach my $subclass ( sort { length $a <=> length $b } keys %c )
    {
[download]

The only place we do a 'use Exception::Class', it is accompanied by a long list of our own classes of Exception we define.

again, I'm not sure what this means, but it feels like a red herring, since this code works 99.99% of the time and is exercised tens of thousands of times per day.

I see op.c got a mountain of work between 5.8.5 and 5.8.8, so now I'm hoping to get approval for testring 5.8.8 to see if the issue clears up. It's still odd that this suddenly became an issue, but perhaps some change in Windows (security patch?) aggravated a known issue in op.c?

Thanks again!

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";
[download]

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
[download]

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"; }
[download]

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.

Thank you! +++++++ I'll see if I can somehow boil this down to a test case...if not, at least it's nice to understand what's happening a little better!

If the problem is the for() bug referred to (and it seems like a good candidate) and a later version of perl doesn't have it fixed, then you could work around the problem by hacking on the module - you could try changing the for() loop to a while loop with an explicit counter on number of iterations.

I you have some example code, please please please reply to the ticket so I can reopen it. Its exeptionally hard to tell whether a bug is fixed or not without some code to test with.