BEGIN {print "Still alive at " . __LINE__ . "\n"}
[download]

When you find it, you will likely have to figure out why it is dying. It may well be due to a bug in Perl 5.10. Do not discount the value of trying to come up with the shortest program you can that crashes. Even if that program is meaningless to you, you can submit it as a bug report and someone else can try to fix it. Even more usefully though, you are likely to learn enough about the problem to figure out how to work around the bug.

Good luck! (And hopefully you do not need to work with much of this previous programmer's code. 6mb and uses no modules???)

I second that.

Another idea would be to truncate the file and see if it doesn't crash. Do a binary search that way. Hopefully, using __END__ will do the trick. Or, use editor's undo feature.

Perhaps it is trying to load a module compiled for perl 5.8.x. To check at the head of the script put

use Data::Dumper;
[download]

BEGIN {
    print 'use <module name> at line ', __LINE__, "\n";
    print Dumper \%INC;
}
[download]

and after each use statement put

If the use call makes it crash, isn't this too late? In that case, the print statement should come before the use call.

If it's not the use calls that makes it crash, then you can postpone the check of %INC until all modules are loaded, for example in a CHECK block, or else, at the top level at the very front of the script. Otherwise, you'll get a lot of nearly identical Dumper data for %INC, which is a lot of noise.

In this case, I'd do this:

#for every module (using Foo::Bar as an example):
BEGIN {
    printf "use Foo::Bar at line %d \n", __LINE__;
}
use Foo::Bar;  # replace with actual module name
BEGIN {
    printf "Foo::Bar loaded OK\n";
}

 
# once for the whole script:
CHECK {
    use Data::Dumper;
    print Dumper \%INC;
}
[download]

If a use call makes it crash, you won't see the associated "module Foo::Bar loaded OK" message. If none did, you'll see the summary for %INC.

I have no idea how you can print the path of a module if just use of it makes perl crash...

p.s. As the OP says, no other than standard modules are used, then just a check of @INC might reveal if there's any suspicious root path in there.

And, oh: don't just install ActivePerl 5.10 on top of the installation of ActivePerl 5.8. Either use a parallel intallation, in a different root directory, or completely uninstall perl first and install everything again. That way you can avoid using any old modules, compiled for AP 5.8.

If you do still have a system running 5.8.x, and this script does still run (and does what it's supposed to do) on that system, I would recommend breaking the big script apart into smaller chunks, testing the "decomposed" version on the 5.8 system to make sure it produces the same results as the original, and port the multi-file version to the 5.10 system.

I would expect that in the process of splitting it up, you will find numerous opportunities to refactor the code and eliminate lots of repetitive content. (One sure way of making a script too long is to use the "copy/paste/modify" style of coding, whereby a few lines of code get repeated dozens of times with minor alterations, instead of being written once as a proper subroutine with sensible parameters.) The app as a whole is likely to end up much smaller as a result, and that would be a Good Thing.

One thing is for certain: if the code gets split into different source files, it will be a lot easier to isolate/locate problems.

If the app needs to be around for a while, I would argue that this is the only sane and sustainable strategy -- don't propagate the mistakes of the programmer who left this mess behind. If/when it needs to be migrated again, it'll be easier at that time if you make the effort to refactor it now. Otherwise, you'll just have to face the same problem again later.

One other thought: do you have access to a unix/linux box that you could try this out on? (Would it make sense to do that, or is the process really Windows-bound?) Options and tools for diagnosis, analysis and refactoring might be better in that other environment.

A more immediate solution is the __END__ token. Stick it in the middle and see if everything works. If it does, then move it to 75%, otherwise move it to 25%. You'll very quickly determine about where the problem is.

Another thing - write tests. Lots and lots of tests.

I am also going to echo the “break it up” admonition. And yes, I know that breaking up is ... well, you know the rest.

Unfortunately, any programmer who built a 6-megabyte single source file never did know what (s)he was doing, but was going for a weird notion of job-security. In the long run, such a program is completely unmanageable, and it becomes a liability to the business. (This could be part of the reason why that person is now a “previous” programmer...)

An arbitrarily-large Perl program can be subdivided into packages with just a little effort. As the file becomes smaller, it will be easier to do. The first step will be to try to map out the big chunks of the existing code which are not used constantly, separating them from the chunks that are common-to-all. A 6-megabyte monstrosity might contain many megabytes of code that are almost never used:   such material can be required when ... well, you know ... when required! :-)

Does anybody know where to get such perl for windows?

Thanks!

Does anybody know where to get such perl for windows?

I don't know of any pre-compiled debug versions of perl for windows, but it's quite easy to build one from source. Both the Win32/Makefile (for use with Visual Studio) and Win32/makefile.mk (for use with MinGW) in the perl source accommodate the building of a debug perl. (See the comments in the configurable section of the relevant makefile - it should just be a matter of uncommenting in one line.)

Cheers,
Rob

use File::Temp;
my $file = shift @ARGV;

my $low=1;
chomp(my $high = `wc -l $file`);
print "File is $high lines\n";

my %tried;
while (my $next=int(($high-$low)/2)+$low) {
  last if $tried{$next}++;
  print "low: $low high: $high next: $next\n";
  my $tmp = File::Temp->new(TEMPLATE => "tmp_XXXXXX", DIR=>".");
  open(my $fh, $file) or die "Can't open $file: $!";
  while (<$fh>) {
    print $tmp "__END__\n" if $. == $next;
    print $tmp $_;
  }
  close $fh;
  $tmp->close();
  my $out = `perl -c $tmp 2>&1`;
  ( $out =~ /syntax OK/ ? $low : $high ) = $next;
}
[download]

use strict;
use warnings;

my $foo=1;

BEGIN { die "Dead\n" }

print "hello\n";
print "hello\n";
print "hello\n";
print "hello\n";
print "hello\n";
print "hello\n";
print "hello\n";
print "hello\n";
print "hello\n";
[download]

Update: I can think of ways this will fail, e.g., if the __END__ line splits up a {...} block you'll get a syntax error which may not have anything to do with the problem you're looking for which will throw this method off...oh, well...back to the drawing board (more testing around the "perl -c" output for those kinds of errors might do the trick, but I'm all out of tuits).

Anyway, you've run it with "perl -d" right? Did that show anything?

Next thing I'd try is running perl within the Visual Studio debugger. You can download the "Express" edition from MS free. That will at least show you the subroutine / symbol where it's dying.

But to be honest, when I've had this kind of problem before it's been pretty inscrutable, e.g. a problem with one Perl XS module causing crash errors elsewhere.

GL, Peter
http://perl.dragonstaff.co.uk

Firstly, I can't believe it's 6MB.

I can't either. My biggest single script is less than 20k, and my average is less than 3.

No error message from perl. I just get standard "application has crashed and was terminated" window.

I just get standard "application has crashed and was terminated" window

I think that indicates that the program has compiled successfully - and that you're getting a segfault (ie runtime error) before any other output has been produced.

Some print "Got to here\n"; statements sprinkled throughout should help determine where the error is occurring.

Cheers,
Rob

Is this some gui-application, or a commandline program started by clicking an icon? Anyway, try to start it from a Dos command shell, i.e. Start->Run->cmd
look at the properties for the shortcut and cd to the right drive / directory accordingly. Starting from a commandline will leave you at the commandline with the possibility that you get some more information when it chrashes.
hth