696039 - Assertion failure: !js_PrototypeHasIndexedProperties(f.cx, obj), at jsarray.cpp:2605

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

Attachment: Valgrind errors from a less-minimized version of the test (opt64).

The following test asserts on mozilla-central revision 67673422f7d2 (options -m -n -a):


gczeal(2);
var lfcode = new Array();
lfcode.push("");
lfcode.push("");
while (lfcode.length > 0) {
        var file = lfcode.shift();
        loadFile(file);
}
function loadFile(lfVarx) {
        try {
                eval("\
                        Array.prototype[30] = 'B';\
                        delete Array.prototype[30];\
                        assertEquals('edcba', a.join(''));\
                ");
        } catch (lfVare) {}
}



S-s because this is possibly gc-related (gczeal required). A less minimized version of the test also showed valgrind errors (see attachment). Let me know if these errors are related or expected.

Comment 1

[Christian Holler (:decoder)]

Forgot to mention that the test does not show any signs of crashes/memory corruptions besides the attached valgrind log from the less-reduced test. Remove s-s if this is confirmed to be harmless.

Comment 2

[Johnny Stenback (:jst)]

David, guessing sg:critical here based on the valgrind log. Please reassign appropriately.

Comment 3

[David Mandelin [:dmandelin]]

I'm pretty sure this is a TI bug. It doesn't look sg:critical to me, though. Brian, could you have a look?

Comment 4

[Daniel Veditz [:dveditz]]

Not critical because web content can never trigger this bug, it's js-shell only?

decoder: please attach the "less minimal" version of the testcase (or file a separate bug if you think it's a separate problem).

Comment 5

[David Mandelin [:dmandelin]]

(In reply to Daniel Veditz from comment #4)
> Not critical because web content can never trigger this bug, it's js-shell
> only?
> 
> decoder: please attach the "less minimal" version of the testcase (or file a
> separate bug if you think it's a separate problem).

I think web content could hit this if a GC came at the right time. I guess it wouldn't be reproducible, though.

Comment 6

[Brian Hackett [Laid off!]]

Attachment: patch

Bogus assert.  When compiling a fast version of Array.shift we check statically that the array prototype does not have indexed properties, and after updating the object call a stub which wraps a memmove().  The stub asserts that the prototype does not have indexed properties, but the assert is inaccurate --- it checks the INDEXED flag on the object, which is, interestingly, less precise than the type information.  When adding an indexed property to an object and deleting it later, the indexed bit sticks to the object but the resulting type information will not have any types in the indexed type set, provided that the compiler nor inference did not query the type information until after the indexed property was deleted.

The valgrind log is separate from this bug, and the involved code looks fine to me.  An array of uint32s with an odd length is being accessed, and I suspect that GCC generated code which used the cell after the end of the array in some way.

Comment 7

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4abbb8b11ffd

Comment 8

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/4abbb8b11ffd

Comment 9

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929