Closed Bug 443569 Opened 16 years ago Closed 16 years ago

Assertion failure: OBJ_IS_NATIVE(obj) after messing with __proto__

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: jruderman, Assigned: mrbkap)

Details

(5 keywords)

Attachments

(2 files, 2 obsolete files)

Loading the testcase makes Firefox die.  Strangely, the JavaScript in the testcase does not break the standalone js shell.

Debug:
Assertion failure: OBJ_IS_NATIVE(obj), at /Users/jruderman/central/mozilla/js/src/jslock.cpp:1205

Opt: Usually hangs, but can crash.

This bug triggers the same assertion that bug 436741 triggered.
Attached patch Proposed fix (obsolete) — Splinter Review
regexp_getProperty doesn't expect the regexp to be on the proto chain of the object that's passed in, so it does a bunch of stuff that requires its object to be a regexp object and one of those things is to lock the object. This patch makes us look up the proto chain for the regexp object.

I'm not sure if I actually need to null-check (are we guaranteed to find the object on the proto chain?) but it felt better to be defensive. I also looked through the rest of the tree and didn't see any other getProperty implementations that would crash if they didn't find their object.
Assignee: general → mrbkap
Status: NEW → ASSIGNED
Attachment #328110 - Flags: review?(brendan)
Attached patch Updated patch (obsolete) — Splinter Review
Sorry for the spam, I noticed that regexp_setProperty needed similar treatment, but failed to qrefresh before I attached the previous patch.
Attachment #328110 - Attachment is obsolete: true
Attachment #328111 - Flags: review?(brendan)
Attachment #328110 - Flags: review?(brendan)
I finally got the stack trace for the crash I hit in a nightly:
http://crash-stats.mozilla.com/report/index/69cf4c2b-499b-11dd-86bb-001cc4e2bf68
Comment on attachment 328111 [details] [diff] [review]
Updated patch

>Don't do things to the object before we're sure it's the right type of object. bug 443569
>
>diff --git a/js/src/jsregexp.cpp b/js/src/jsregexp.cpp
>--- a/js/src/jsregexp.cpp
>+++ b/js/src/jsregexp.cpp
>@@ -3622,12 +3622,17 @@ regexp_getProperty(JSContext *cx, JSObje
> 
>     if (!JSVAL_IS_INT(id))
>         return JS_TRUE;
>+    while (JS_GET_CLASS(cx, obj) != &js_RegExpClass) {

Use OBJ_GET_CLASS inside the engine, avoid an API call.

>+        obj = OBJ_GET_PROTO(cx, obj);
>+        if (!obj)
>+            return JS_TRUE;

This reminds me of code I've written and/or seen elsewhere, going back to window objects in MozillaClassic. Is it similar to code you know of in the modern world?

r=me with OBJ_GET_CLASS instead of JS_GET_CLASS.

/be
Attachment #328111 - Flags: review?(brendan) → review+
(In reply to comment #4)
> This reminds me of code I've written and/or seen elsewhere, going back to
> window objects in MozillaClassic. Is it similar to code you know of in the
> modern world?

We use it in just about every [GS]etProperty hook outside of the engine (usually hidden in a FindWrapper type function). Most hooks in the engine avoid the need by calling JS_GetInstancePrivate on the incoming object and bailing if it does not return private data.
This is what I'm going to check in when I next get a chance.
Attachment #328111 - Attachment is obsolete: true
Attachment #328309 - Flags: review+
Pushed as changeset 3916fa3c8467.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment on attachment 328309 [details] [diff] [review]
Updated to comments

This applies to the 1.9 branch.
Attachment #328309 - Flags: approval1.9.0.2?
Let's get a test for this before landing in 1.9.0.x.
Flags: in-testsuite?
Whiteboard: [needs automated test]
/cvsroot/mozilla/js/tests/js1_5/extensions/regress-443569.js,v  <--  regress-443569.js
initial revision: 1.1

mozilla-central: changeset:   16481:d634d3d4388e
Flags: in-testsuite?
Flags: in-testsuite+
Flags: in-litmus-
Whiteboard: [needs automated test]
Comment on attachment 328309 [details] [diff] [review]
Updated to comments

Approved for 1.9.0.2. Please land in CVS. a=ss
Attachment #328309 - Flags: approval1.9.0.2? → approval1.9.0.2+
Fix checked into the 1.9 branch.
/me hands mrbkap the fixed1.9.0.2 keyword. ;)
Keywords: fixed1.9.0.2
verified fixed 1.9.0/trunk linux/mac/win
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: