Last Comment Bug 696039 - Assertion failure: !js_PrototypeHasIndexedProperties(f.cx, obj), at jsarray.cpp:2605
: Assertion failure: !js_PrototypeHasIndexedProperties(f.cx, obj), at jsarray.c...
Status: RESOLVED FIXED
js-triage-done
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Linux
: -- critical (vote)
: mozilla11
Assigned To: Brian Hackett (:bhackett)
:
: Jason Orendorff [:jorendorff]
Mentors:
Depends on:
Blocks: langfuzz
  Show dependency treegraph
 
Reported: 2011-10-20 05:41 PDT by Christian Holler (:decoder)
Modified: 2013-01-19 14:35 PST (History)
6 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Valgrind errors from a less-minimized version of the test (opt64). (16.83 KB, text/plain)
2011-10-20 05:41 PDT, Christian Holler (:decoder)
no flags Details
patch (699 bytes, patch)
2011-11-17 20:39 PST, Brian Hackett (:bhackett)
dvander: review+
Details | Diff | Splinter Review

Description Christian Holler (:decoder) 2011-10-20 05:41:46 PDT
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.
Comment 1 Christian Holler (:decoder) 2011-10-20 05:42:59 PDT
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, jst@mozilla.com) 2011-11-16 16:38:46 PST
David, guessing sg:critical here based on the valgrind log. Please reassign appropriately.
Comment 3 David Mandelin [:dmandelin] 2011-11-17 11:38:08 PST
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] 2011-11-17 13:18:48 PST
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] 2011-11-17 15:02:57 PST
(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 (:bhackett) 2011-11-17 20:39:11 PST
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.
Comment 7 Brian Hackett (:bhackett) 2011-11-21 16:16:25 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/4abbb8b11ffd
Comment 8 Ed Morley [:emorley] 2011-11-22 09:09:19 PST
https://hg.mozilla.org/mozilla-central/rev/4abbb8b11ffd
Comment 9 Christian Holler (:decoder) 2013-01-19 14:35:47 PST
Automatically extracted testcase for this bug was committed:

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

Note You need to log in before you can comment on or make changes to this bug.