Closed
Bug 781022
Opened 12 years ago
Closed 12 years ago
IonMonkey: Crash [@ js::gc::MarkGCThingRoot]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
firefox-esr10 | --- | unaffected |
People
(Reporter: gkw, Assigned: dvander)
References
Details
(Keywords: crash, regression, testcase, Whiteboard: [ion:p1:fx18])
Crash Data
Attachments
(3 files, 1 obsolete file)
a = Uint8ClampedArray; for each(c in [0]) { gczeal(10) } try { (function () { Object.defineProperty(this, "b", { get: function () { a.subarray() } }) })() (b) } catch (e) {} try { (function () { Object.defineProperty(this, "a", { get: function () { return Uint8ClampedArray() } }) })() (2 instanceof b) } catch (e) {} (b instanceof 2) crashes js opt shell on IonMonkey changeset b2361e15b665 with --ion-eager at js::gc::MarkGCThingRoot when the testcase is passed in as a CLI argument, does not seem to cause anything on debug shell. s-s because gc is on the stack, and also because a weird memory address 0x7fff000001f5 is being accessed. autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 103056:9f3dc298e25b user: David Anderson date: Thu Aug 02 14:17:13 2012 -0700 summary: MIR nodes should use CompilerRoot, not HeapPtr (bug 779812, r=sstangl).
Reporter | ||
Comment 1•12 years ago
|
||
This is the correct stack.
Reporter | ||
Updated•12 years ago
|
Attachment #649837 -
Attachment is obsolete: true
Reporter | ||
Comment 2•12 years ago
|
||
Assignee | ||
Comment 3•12 years ago
|
||
Whoops, when I changed this to use CompilerRootNode I didn't notice that Entries were created on the stack.
Comment 4•12 years ago
|
||
Comment on attachment 649941 [details] [diff] [review] fix Review of attachment 649941 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/ion/MIR.h @@ +3935,5 @@ > > public: > InlinePropertyTable(jsbytecode *pc) > + : pc_(pc), priorResumePoint_(NULL) > + { Not sure if style guides include this, but I think it's good to refer to all members in constructor initializers (i.e. have an empty initialier for entries_ in this case). When reading code it makes it easier to figure out the initial state of the object without having to look at the member declarations.
Attachment #649941 -
Flags: review?(kvijayan) → review+
Assignee | ||
Updated•12 years ago
|
Whiteboard: [ion:p1:fx18]
Assignee | ||
Comment 5•12 years ago
|
||
I don't have a particular opinion on style there, but I re-added the initialization. Pushed as: https://hg.mozilla.org/projects/ionmonkey/rev/826f67c39bdc
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Status: RESOLVED → VERIFIED
Comment 6•12 years ago
|
||
JSBugMon: This bug has been automatically verified fixed.
Updated•12 years ago
|
status-firefox-esr10:
--- → unaffected
Updated•9 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•