Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!think.com!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: Bug
Message-ID: <10398@jpl-devvax.JPL.NASA.GOV>
Date: 15 Nov 90 19:14:52 GMT
References: <1990Nov15.003912.26468@uvaarpa.Virginia.EDU>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 67

In article <1990Nov15.003912.26468@uvaarpa.Virginia.EDU> worley@compass.uucp writes:
: This program dumps core.  I'm sure that it's my problem, but exactly
: what am I doing that I'm not allowed to?  (I'm running PL41.)
: 
: Dale
: 
: Dale Worley		Compass, Inc.			worley@compass.com
: --
: True, money _can't_ buy happiness, but it isn't happiness I want.  It's money.
: 
: #! /usr/local/bin/perl
: 
: sub put {
: 	local(%x);
: 	local(*array) = *x;
: 	$save = *x;
: 	$array{'a'} = 'b';
: 	print "value saved\n";
: }
: 
: sub get {
: 	local(*array) = $save;
: 
: 	print "fetching...\n";
: ####### This line causes a segmentation fault:
: 	$array{'a'};
: 	print "value retrieved\n";
: }
: 
: &put();
: 
: print "\$save = '$save'\n";
: 
: print &get(), "\n";

A symbol table entry such as *x merely contains pointers to various
objects called by the name 'x'.

What's happening is that you're making a copy of the symbol table entry
for x while it has a pointer to a local copy of %x.  When you leave the
scope of the local in &put, the local %x is destroyed, and the *x symbol
table entry is restored to having it's global %x array value.  But your
copy of the symbol table entry in $save still has the pointer to the
local array that has been freed.  So naturally, when you try to dereference
that pointer, you blow up.

The solution, of course, will be to put reference counts on things so
they aren't freed till all their references go away.  This has been
planned for some time, but probably won't happen until after 4.0 comes
out.  When it does happen, most of the advice about $&, $1, $2... being
slow will become obsolete, since I'd then be able to make those just
refer into the string that was searched, instead of making a copy of
the string as I do now.  In other words, move to more of a
copy-on-write implementation, hopefully in a topologically transparent
fashion.

On the other hand, there's already a lot of overhead for each string,
and adding a reference count won't help with that.  But memory's getting
cheaper.  I might be able to shoehorn a reference count in on top of
the numeric value by disallowing multiple references on scalars with
a numeric value, but it wouldn't be as clean.  I do occasionally worry
about that.  :-)

If Perl were written in proper C++, it would be a lot easier to understand,
and would run in twice the memory...

Larry