Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!jarthur!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: Nasty bug ... somewhere in DBM (I think)
Message-ID: <7473@jpl-devvax.JPL.NASA.GOV>
Date: 20 Mar 90 03:25:38 GMT
References: <1990Mar19.183022.5325@eci386.uucp>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 16

In article <1990Mar19.183022.5325@eci386.uucp> clewis@eci386 (Chris Lewis) writes:
: Something to do with an interaction between the DBM caching mechanism and
: array assignment temporaries perhaps?

Precisely.  An rvalue passes references up the call tree via the stack, and
everything assumes that the reference won't be destroyed until the value is
copied to somewhere "safe".  The DBM cache code assumed it could just pass
a reference to a cache entry.  This is obviously bogus, since a reference
to multiple DBM entries can cause one entry to flush the another's cache
entry.  I'll fix it, as soon as I figure out if there's some way to avoid
copying the data every single time, which would be a performance hit.

What might be harder to fix would be assignment to a list of DBM lvalues.
I'm not sure how to fix that yet.  Meanwhile, don't do that...

Larry