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];

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

Injection?

(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)

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.

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.

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!

Tamarin isn't maintained anymore. WONTFIX remaining bugs.