Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!rpi!bu.edu!nntp-read!composer
From: composer@chem.bu.edu (Jeff Kellem)
Newsgroups: comp.lang.perl
Subject: possible patchlevel 37 bug (memory leak?)
Message-ID: <COMPOSER.90Oct24220939@chem.bu.edu>
Date: 25 Oct 90 02:09:39 GMT
Sender: news@bu.edu.bu.edu
Reply-To: composer@chem.bu.edu
Organization: Boston University Chemistry Department
Lines: 48

The following will make perl crash with a segmentation fault on the following
machines:
		Sun 3/SunOS 4.0.3
		Encore Multimax/UMAX 4.2

Both were compiled using gcc 1.37.1 and bison 1.11, with debugging and
optimization.

#!/usr/local/bin/perl
open(FOO,'somefile') || die "$0 can't open somefile: $!\n";
$_ = "bar";
s/^\w//;

It actually crashes before attempting to execute the script, sometime
during compilation.  The `-c' option is used below to not even bother
trying to execute the script.  It gets through producing the compiled
regular expression, but crashes before displaying the compiled syntax
tree.

Here's the output of "perl -D1536 -c bug-pl37":

first 1 next 12 offset 0
 1:BRANCH(13)
 5:BOL(9)
 9:ALNUM(13)
13:END(0)
anchored 
Segmentation fault (core dumped)

Under patchlevel 28, the above would also output the compiled syntax
tree.  In other words, it works under patchlevel 28. Note that the above
script is not supposed to do anything useful.  It's just an example that
seems to crash perl.  ;-{

It looks like it could have to do something with the "open .. || die .."
line.  Removing the "|| die .." section doesn't crash perl.  Also,
removing just the "$0" (or just the "$!") in the "die" call doesn't crash
perl.  Possibly some code/data getting overwritten somewhere...?  :-(

Any ideas Larry?  Could this have something to do with the new code
forcing variables into a package?

Good luck!

				-jeff

Jeff Kellem
Internet: composer@chem.bu.edu