AllBackJack has asked for the wisdom of the Perl Monks concerning the following question:

Script just stops working with a popup. I'm trying to figure this out. Using Strawberry perl. Win10 log file. I'm hoping this may tell someone what I'm doing wrong or the problem is or simply how to get around it. The Exception is a bad pointer reference in the dll.

Faulting application name: perl.exe, version: 5.24.0.1, time stamp: 0x
+57323a0d
Faulting module name: perl524.dll, version: 0.0.0.0, time stamp: 0x573
+239d2

Exception code: 0xc0000005
Fault offset: 0x000000000007a3ee
Faulting process id: 0x3d18
Faulting application start time: 0x01d27b7a00d0b9b8
Faulting application path: C:\StrawberryPerl\perl\bin\perl.exe
Faulting module path: C:\StrawberryPerl\perl\bin\perl524.dll
Report Id: 8e19886c-5bf8-4d4f-aef1-84a7b8e365aa
Faulting package full name: 
Faulting package-relative application ID:

[download]

I use OptiPerl for editing and debugging, and script fails whether I run it on a command line or with OptiPerl. Always about the same spot. And if I'm being kind of obscure it's because the problem is obscure.

When debugging, I can simple step. Although it's a simple recursive program portion of a huge script, when I single step in it doesn't fail right away, but there is a pause of 5 to 10 seconds. No threads running or anything.

Basically the spot is (with more and more debugging code added):

 if ( ( $g = $Grouping[$i][GEXTGRP] ) != $l ) {
  print "Calling BreakUpGroupingByGroup.\n";
  return BreakUpGroupingByGroup( __LINE__, $match );
 }

[download]

$match is a simple variable (0 or 1).

BreakUpGroupingByGroup is executed many times. But when it fails, first statement (debug print) in the sub isn't getting executed. Succeeds many times before.

sub BreakUpGroupingByGroup {
  my ( $lineno, $match ) = (@_);
  print "In BreakUpGroupingByGroup( $lineno, \$match=$match).\n";
.......

[download]

Fails repeatedly in exact same instance.

Replies are listed 'Best First'.
Re: Win10: Getting popup "Perl Interpreter has stopped working"
by kcott (Archbishop) on Jan 31, 2017 at 05:49 UTC

    G'day AllBackJack,

    Please put your code and data within '<code>...</code>' tags. See "Writeup Formatting Tips" for details.

    Your first line of code appears like this: 

    if ( ( $g = $Grouping[$i][GEXTGRP] ) != $l ) {

    [download]

    However, $i and GEXTGRP are rendered as links. So, if you pasted a verbatim copy of your code, it really looks like this: 

    if ( ( $g = $Grouping[[$i]][[GEXTGRP]] ) != $l ) {

    [download]

    I suspect the doubled-up, square brackets are probably the source of the problem.

    — Ken

[reply]
[d/l]
[select]
Re: Win10: Getting popup "Perl Interpreter has stopped working"
by FreeBeerReekingMonk (Deacon) on Jan 31, 2017 at 19:07 UTC
    I think the Array-of-array is becoming too big due to autovivification, see this simple example:

    fbrm@monastery:~$ perl -MData::Dumper -E '$Q=$A[4][6]; say Dumper \@A'
$VAR1 = [
          undef,
          undef,
          undef,
          undef,
          []
        ];

    [download]

    See how there are many undef's in the array (not sparse)... so you must change your code to probe first for existence of the array spot, and only then ask for the value (to avoid autovivification). Now, when creating the AoA, you also get this (perl -MData::Dumper -E '$A[4][6]=11;say Dumper \@A') so maybe switch to Hashes/HoH?

    EDIT: added a better example with seemly only a 'read', here is the old example, which is clearly an assign: 

    fbrm@monastery:~$ perl -MData::Dumper -E '$A[4]="hi"; say Dumper \@A'
$VAR1 = [
          undef,
          undef,
          undef,
          undef,
          'hi'
        ];

    [download]

    edit2: You can check this hypothesis with profiling heap memory usage on perl

[reply]
[d/l]
[select]

      Thanks for your reply. I think you are close to the source of the problem, in it has to do with array sparseness or compaction.

      What I found is that I have an AOA (with some sub-AOA's), and items are deleted or splice'd out. All the operations on the top @array look "simple", no ref's to routines or anything.

      Yet when it came to removing the last item of an array by a splice (e.g. splice( @array, 0, 0) it seemed to work but later on I get the fault. If I instead put a check before the splice and did

      if( scalar( @array ) > 1 ) {
  splice(@array,$i,0);
} else {
  @array = ();
}

      [download]

      the exception goes away.

      I'm not sure that this is really solving the problem, or just pushing it elsewhere.

      This script is old and has been working for eons (although only used a couple times a year). The incoming data naturally changes. However, strawberry perl itself does get updated and although I doubt it I'm wondering if something got changed in perl such that this is now showing up.

      While trying to find a solution to this problem I did find this posting in PerlMonks from January 25, 2017 and I'm wondering if there is possibly some underlying cause (I do use HOH's and ENV items): http://www.perlmonks.org/?node_id=1180341

[reply]
[d/l]
        If you suspect it is because of a slow march into Unicode, Try putting use bytes; at the beginning of your code. Who knows... it might work.
        (some caveats apply. For example, if your perlscript file itself has a BOM or is not ascii, see perlunicode)

        how about installing virtualbox for Windows, then downloading a live ISO from any modern linux, and try your data on Linux. If your program does not die, then it's a Windows only artifact. And you might want to add your findings to the bug in the hope it gets more priority/attention.

        Or, find an older version of perl, and install that on a Windows machine, and test that out. Of course, you have one year, by then, hopefully, the bug is fixed.

[reply]
[d/l]

Back to Seekers of Perl Wisdom