Path: utzoo!attcan!telly!eci386!clewis
From: clewis@eci386.uucp (Chris Lewis)
Newsgroups: comp.lang.perl
Subject: Nasty bug ... somewhere in DBM (I think)
Message-ID: <1990Mar19.183022.5325@eci386.uucp>
Date: 19 Mar 90 18:30:22 GMT
Reply-To: clewis@eci386 (Chris Lewis)
Organization: Elegant Communications Inc., Toronto, Canada
Lines: 69

I've encountered what I think is a relatively drastic bug, worse,
it may be hellish to find/reproduce.  Then again, we know how good
Larry is at this.....

Perl 3, PL8 & PL12, 386/ix 1.0.6, "old" dbm configured.

As part of some relatively humongous perl code, I save things in
a content-addressible array, along the lines of:

	$sardb{'file-sz', $date} = <some number>;

[Hint, this is a sar report analyser....  $date looks like "nn:nn:nn".]

I skip through the dates that are valid, and do something like:
    if ($sardb{'file-sz', $date}) {	# have data from sar's "file" table
	local($files, $filesz, $fileov,
	      ....) = ($sardb{'file-sz', $date},
		       $sardb{'file-max', $date},
		       $sardb{'file-ov', $date},
		       ....
		      );
	use the variables fetched for analysis

There's about 12 entries in both the local(...) and ($sardb...) arrays.
In perl3 (PL 8 and 12) *some* entries are coming back as null, worse,
*some* entries are coming back with the wrong value.  The "wrong value" is,
however, a valid value for another entry.  Eg: I install

    $sardb{'file-sz', ...} = 100;
    $sardb{'file-max', ...} = 300;
    $sardb{'file-ov', ...} = 0;

and get back something like:

    $files = 100;
    $filesz = 100;
    $fileov = '';

This occurs *only* when the sardb array is associated with a DBM file via
dbmopen(...).  If I comment out the dbmopen line it works perfectly.
When I convert the big array assignment to individual ones, ala:

    $files = $sardb{'file-sz', ...};
    $filesz = $sardb{'file-max', ...};
    $fileov = $sardb{'file-ov', ...};

It will work perfectly *with* DBM.  Interestingly enough, it seems to be 
reasonably data-dependent, in that if the number of dates in the DBM
is is 2 or 140, the fetches blow the same way on the same dates.

Further, when I write a DBM traversal stand-alone in C or perl, the data
comes back just fine.

If it matters any, in the cases that I'm dealing with, the *last* sardb
reference in the array assignment hasn't been assigned to (but my program 
is guarding against that anyways).

Something to do with an interaction between the DBM caching mechanism and
array assignment temporaries perhaps?

The code is too big to reproduce.  Larry if you have problems finding this
I can try narrowing it down to a simpler program, but it will take a while.
I was hoping that this would be enough for you to find it.

I will be upgrading to PL15 shortly and testing again.
-- 
Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list