composer@chem.bu.edu (Jeff Kellem) (10/25/90)
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.edulwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/26/90)
In article <COMPOSER.90Oct24220939@chem.bu.edu> composer@chem.bu.edu writes:
: 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
:
: #!/usr/local/bin/perl
: open(FOO,'somefile') || die "$0 can't open somefile: $!\n";
: $_ = "bar";
: s/^\w//;
:
: 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?
No, it turns out to be simply that $0 was still being treated as a magical
variable in one spot but not in another. (It used to be a magical synonym
for $&, but now it's an ordinary variable that just happens to be
initialized to the name of the script.) The bug is triggered when it
enters the default case of the switch that processes magical variables.
Ordinarily such a variable is a user-defined variable (via usersub.c),
so it tries to interpret it as such. Most of the time, the paranoia
checks in that case reject it as a user-defined variable, but in your
case perl had created $0 with a string value (taken off the free STR list)
that looked enough like a user-defined variable to get past the censors.
The trivial fix is to not mark $0 as magical in perly.c. >>patch38
Larrykgallagh@digi.lonestar.org (Kevin Gallagher) (10/30/90)
In article <10108@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >In article <COMPOSER.90Oct24220939@chem.bu.edu> composer@chem.bu.edu writes: >No, it turns out to be simply that $0 was still being treated as a magical >variable in one spot but not in another. >[stuff deleted] > >The trivial fix is to not mark $0 as magical in perly.c. >>patch38 > Several people here use the perl debugger quite a lot. We all got bit by this $0 problem causing a "segmentation fault". Rather than back out pl 37, I thought it should be easy to fix perly.c myself, encouraged by your comment above. Well, I tried and failed. Your comment suggested to me that the following change should be made: From: magicalize("!#?^~=-%0123456789.+&*()<>,\\/[|`':\024"); To: magicalize("!#?^~=-%123456789.+&*()<>,\\/[|`':\024"); which just deletes "0" from the list. It did not work. Am I missing something obvious? -- ---------------------------------------------------------------------------- Kevin Gallagher kgallagh@digi.lonestar.org OR ...!uunet!digi!kgallagh DSC Communications OR apcihq!apcidfw!digi!kgallagh ----------------------------------------------------------------------------
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/30/90)
In article <1195@digi.lonestar.org> kgallagh@digi.lonestar.org (Kevin Gallagher) writes: : Several people here use the perl debugger quite a lot. We all got bit by this : $0 problem causing a "segmentation fault". Rather than back out pl 37, I : thought it should be easy to fix perly.c myself, encouraged by your comment : above. Well, I tried and failed. Your comment suggested to me that the : following change should be made: : : From: magicalize("!#?^~=-%0123456789.+&*()<>,\\/[|`':\024"); : To: magicalize("!#?^~=-%123456789.+&*()<>,\\/[|`':\024"); : : which just deletes "0" from the list. It did not work. Am I missing : something obvious? You also have to say 713c713 < str_set(STAB_STR(tmpstab),origfilename); --- > str_set(stab_val(tmpstab),origfilename); Larry
kpc00@JUTS.ccc.amdahl.com (kpc) (10/31/90)
Did nobody outside of this site get my "1 2 3" post here? (About a2p, speed, scheme, etc?) In article <10163@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: In article <1195@digi.lonestar.org> kgallagh@digi.lonestar.org (Kevin Gallagher) writes: : Several people here use the perl debugger quite a lot. We all got bit by this : $0 problem causing a "segmentation fault". Rather than back out pl 37, I What are the symptoms of the bug? My a2p output crashes the debugger. Thanks. -- If you do not receive a reply from me, please resend your mail; occasionally this site's mail gets delayed. Neither representing any company nor, necessarily, myself.