592358 - Deletion on Array may produce an unexpected value in that Array.

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect, P2)

Description

[Brent Baker]

Deleting an array element does not always guarantee that the element has been null'd out and may still be accessible:


Steps to reproduce:
1. compile the following code:
var a:Array = [];

function put(k:uint):void {
    a[k] = Math.random();
}

function remove(k:uint):void {
    var before:Number = a[k];
    delete a[k];
    var after:Number = a[k];
    if (a[k] != null) {
       trace("k: " + k + " "+
		    	  "Incorrect deletion:" +
			  "before=" + before + "," +
			  "after=" + after);
    }
}

for (var i:uint = 0;;i++) {
    put(uint(Math.random()*4));
    remove(uint(Math.random()*4));
}
 
Actual Results:
Will see a bunch of traces as accessed array element after deletion is not null
 
Expected Results:
Nothing should be traced
 
Workaround (if any):
Delete it twice! 
delete a[k];
delete a[k];

Comment 1

[Brent Baker]

Jira transfer: http://bugs.adobe.com/jira/browse/FP-2798

Comment 2

[Lars T Hansen]

Injection?

Comment 3

[Brent Baker]

(In reply to comment #2)
> Injection?

Not an injection, tested with coral fp10 and fp9 shells, same results, able to access deleted array element periodically (array[x]!=null)

Comment 4

[Lars T Hansen]

Attachment: Better test case

The original test case is a little confused because it operates on uninitialized array elements and compares a Number value to null, which it can never be.  This test case is less confused.  I've also limited the number of iterations in order to stop spewing output forever.  In a small number of runs the limited test case will not find any errors, but usually it'll find several.  Run it a few times.

Comment 5

[Lars T Hansen]

Attachment: More elaborate test case

This test case is parameterized in various ways, does not dump a lot of output, and computes interesting summary statistics.

Based on a run with 1e7 iterations:

The failure rate varies from about 0.2% on short (10-element) arrays to 0.02% on long (100-element) arrays.

The failures are /always/ concentrated in the low index range between indices 1 and 7, even for the long array.

(Since failure is correlated with a low index and a 100-element array hits low indices only 1/10 as much of the time its failure rate should be 1/10 lower, as it is.  A quick test with an array of length 1000 and 1e6 iterations bears this out: its failure rate is 0.002%.)

The value that is read from a deleted element was /never/ present in the input array before the delete, so it must be garbage left over from a previous iteration or from the implementation.  Garbage values are so low - this test case uses integers, not floats - that the garbage is certainly not a pointer value.

I've verified that the random selection of indices for putting and removing are distributed uniformly so any bias comes from elsewhere.

Comment 6

[pop.atry]

Array.splice(i, 1) also has this problem. Especially when you splice an array after some set/delete operation.

Once Array.splice goes wrong, index of the last element will equal to Array.length!

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.