Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!jpl-devvax!lwall From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Newsgroups: comp.lang.perl Subject: Re: possible patchlevel 37 bug (memory leak?) Message-ID: <10108@jpl-devvax.JPL.NASA.GOV> Date: 25 Oct 90 18:17:09 GMT References: Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 33 In article 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 Larry