Closed Bug 418776 Opened 14 years ago Closed 14 years ago

Assertion failure: !OBJ_GET_PARENT(cx, obj), at mozilla/js/src/jsobj.c:2648


(Core :: XPConnect, defect, P2)






(Reporter: kinetik, Assigned: jst)



(Keywords: regression)


(3 files)

The attached testcase causes a fatal (in debug builds) assertion in the JS engine: !OBJ_GET_PARENT(cx, obj), at mozilla/js/src/jsobj.c:2648.  I ran into this on a current trunk debug build while modifying a testcase based on the one in bug #313462 comment #13.  Originally seen on a Mac build, but also reproduced on a few day old Linux build.

I'll add the complete backtrace as an attachment since backtraces aren't particularly readable when pasted into comments.
Attached file backtrace
I don't crash with a debug build from this morning. Perhaps fixed by bug 418540 ?
I can still reproduce this.  A key point I didn't realise earlier is that the testcase must be loaded via file:///.
confirmed, file:/// only crash. :-/
This looks more like a DOM bug to me.
Assignee: general → nobody
Component: JavaScript Engine → DOM
QA Contact: general → general
I get this any time I do alert(window.frames[0]) and that frame is cross-origin.  I will lay bets this is XOW fallout.  We should fix this.
Component: DOM → XPConnect
Flags: blocking1.9?
QA Contact: general → xpconnect
Assignee: nobody → jst
Blocks: xow
Flags: blocking1.9? → blocking1.9+
Keywords: regression
Priority: -- → P2
Attachment #310125 - Flags: superreview?(mrbkap)
Attachment #310125 - Flags: review?(mrbkap)
Attachment #310125 - Flags: superreview?(mrbkap)
Attachment #310125 - Flags: superreview+
Attachment #310125 - Flags: review?(mrbkap)
Attachment #310125 - Flags: review+
Closed: 14 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
Verified fixed using the testcase and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050614 Minefield/3.0pre + on Mac 10.5

I get no error when i load the testcase, the only "error" in the Debug Output/Error Console is :

Error: A script from "" was denied UniversalBrowserRead privileges.
Source File:
Line: 5

but i think this is expected -> Verified fixed
Carsten, note that this was only easily reproducible in a debug build; I'm not sure there were any obvious issues visible in a nightly for this bug.
fwiw, I can't reproduce the assertion failure with today's debug build on centos5 with either the bugzilla attachment or a version loaded from file: after granting the access.
You need to log in before you can comment on or make changes to this bug.