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

RESOLVED FIXED in mozilla11

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: decoder, Assigned: bhackett)

Tracking

(Blocks: 1 bug, {assertion, testcase})

Trunk
mozilla11
x86
Linux
assertion, testcase
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: js-triage-done)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 568362 [details]
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.
(Reporter)

Comment 1

6 years ago
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.

Updated

6 years ago
Attachment #568362 - Attachment mime type: text/x-log → text/plain
David, guessing sg:critical here based on the valgrind log. Please reassign appropriately.
Assignee: general → dmandelin
Whiteboard: js-triage-needed → [sg:critical] js-triage-needed
I'm pretty sure this is a TI bug. It doesn't look sg:critical to me, though. Brian, could you have a look?
Assignee: dmandelin → bhackett1024

Updated

6 years ago
status-firefox10: --- → affected
status-firefox11: --- → affected
status-firefox8: --- → wontfix
status-firefox9: --- → affected
tracking-firefox10: --- → +
tracking-firefox11: --- → +
tracking-firefox8: --- → +
tracking-firefox9: --- → +
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).
status-firefox10: affected → ---
status-firefox11: affected → ---
status-firefox8: wontfix → ---
status-firefox9: affected → ---
tracking-firefox10: + → ---
tracking-firefox11: + → ---
tracking-firefox8: + → ---
tracking-firefox9: + → ---
(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.
(Assignee)

Comment 6

6 years ago
Created attachment 575378 [details] [diff] [review]
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.
Attachment #575378 - Flags: review?(dvander)
(Assignee)

Updated

6 years ago
Group: core-security
Whiteboard: [sg:critical] js-triage-needed → js-triage-needed
(Assignee)

Updated

6 years ago
Whiteboard: js-triage-needed → js-triage-done
Attachment #575378 - Flags: review?(dvander) → review+
(Assignee)

Comment 7

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

Comment 8

6 years ago
https://hg.mozilla.org/mozilla-central/rev/4abbb8b11ffd
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
(Reporter)

Comment 9

4 years ago
Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.