Closed Bug 635195 Opened 15 years ago Closed 15 years ago

Assertion failure: !wp->setter, at jsdbgapi.cpp:781

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: decoder, Assigned: jorendorff)

Details

(Keywords: assertion, regression, testcase, Whiteboard: [fixed-in-tracemonkey])

Attachments

(1 file, 1 obsolete file)

The following code asserts on TM tip: this.__defineSetter__("x", Function); this.watch("x", eval("with ({}) { for (var x in {}); } (function() { return delete x; })")); TrySomething( "x = \"hi\"", true ); function TrySomething( expression, throwing ) { eval( expression ); } The first bad revision is: changeset: 62178:589bb166be02 user: Jason Orendorff date: Tue Feb 08 16:09:33 2011 -0600 summary: Bug 627984 - Tighten up assertions in JSObject::methodReadBarrier. r=brendan.
Attached patch removes the assert (obsolete) — Splinter Review
I've looked into the code and I think the assert on line 781 in jsdbgapi.cpp isn't necessary. It will assert if the shape is false and there is a setter defined. That's the case when you delete a defined setter in the watch function. When you delete the assert, the code will just complete the watchpoint and the just deleted setter will not be called. (Like it should be, I think) So the included patch only removes the assert reduced testcode: ----------------- this.__defineSetter__("x", Function); this.watch("x", function() { delete x; }); x = "hi";
Thanks for the patch. I think this is basically correct but I want to look at all the code a little more before committing the fix. The worst case if setter is completely wrong is a crash during GC. Taking.
Assignee: general → jorendorff
Comment on attachment 513517 [details] [diff] [review] removes the assert Yep, this is right. I'll add the test to it, then ask for approval to land for FF4.
Attachment #513517 - Flags: review+
Attachment #513517 - Attachment is obsolete: true
Attachment #513626 - Flags: review+
Attachment #513626 - Flags: approval2.0?
Seeking approval since this is basically zero-risk (it removes a DEBUG-mode assertion) and assertions are bad.
Attachment #513626 - Flags: approval2.0? → approval2.0+
Whiteboard: [fixed-in-tracemonkey]
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
A testcase for this bug was automatically identified at js/src/tests/js1_8_5/regress/regress-635195.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: