When navigating back/forward: ASSERTION: Hmm, somebody did something evil?: '::JS_GetPrototype(proto) && JS_GetClass(::JS_GetPrototype(proto)) == sObjectClass', file nsDOMClassInfo.cpp, line 4906

VERIFIED FIXED in mozilla13

Status

()

Core
DOM
--
major
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: dholbert, Assigned: Bobby Holley (parental leave - send mail for anything urgent))

Tracking

({assertion, regression})

Trunk
mozilla13
assertion, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

STR:
 0. Have a debug m-c build from today or later.
 1. Visit http://ftp.mozilla.org/pub/mozilla.org/README
 2. In the same tab, now visit http://ftp.mozilla.org/
 3. Hit "back" button. (or press Alt+LeftArrow)

ACTUAL RESULTS:
{
###!!! ASSERTION: Hmm, somebody did something evil?: '::JS_GetPrototype(proto) && JS_GetClass(::JS_GetPrototype(proto)) == sObjectClass', file ../../../mozilla/dom/base/nsDOMClassInfo.cpp, line 4906
}

I hit this 100% of the time, using a fresh profile w/ a linux 64-bit debug build from today. (revision c1e5daa36ab2)

I chose the URLs above just because they're both very simple pages, but I'm pretty sure this happens on most/all pages, when you navigate forward or back.
Created attachment 603509 [details]
backtrace

The assertion is:
> NS_ASSERTION(::JS_GetPrototype(proto) &&
>                JS_GetClass(::JS_GetPrototype(proto)) == sObjectClass,
>                "Hmm, somebody did something evil?");

When this fails, JS_GetClass(::JS_GetPrototype(proto)) is a JSClass with .name == "Global Scope Polluter", whereas sObjectClass has .name == "Object".

I'm attaching a backtrace of the assertion failure.  (Ignore stack level #0 & #1 -- those are just an artifact of me using XPCOM_DEBUG_BREAK=suspend to catch the assertion-failure.  Stack level #2 is the actual assertion-failure, in nsDOMClassInfo::PostCreatePrototype.)
(Just deleted my objdir and rebuilt from scratch to be sure this wasn't some cruft in my objdir.  Still able to reproduce.)

Today is the first I've seen this assertion, so I suspect this regressed from a recent regression.

Looking at the recent landings, I suspect this cset (or one of its friends)...
{
8277b919772d Bobby Holley — Bug 720580 - Kill temporary globals. r=mrbkap This patch breaks the "every commit is a 100% correct tree" invariant a little bit, because constructors and prototypes for DOM globals are broken (PostCreatePrototype never gets called). This is fixed in the next patch. Doing it this way makes for a cleaner series of commits, and the browser still builds and runs fine.
http://hg.mozilla.org/mozilla-central/rev/8277b919772d
}
...given the mention of PostCreatePrototype in the commit message (the function w/ the failing assertion).
(In reply to Daniel Holbert [:dholbert] from comment #2)
> Today is the first I've seen this assertion, so I suspect this regressed
> from a recent regression.
(er "from a recent commit")
This is almost certainly me. Investigating.
Assignee: nobody → bobbyholley+bmo
Created attachment 603836 [details] [diff] [review]
Only call FinishInitForWrappedGlobal when we just created a global. v1

Without this patch, we call the above when restoring things out of the bfcache, which is bad. It must be called exactly once.

Flagging mrbkap for review.
Attachment #603836 - Flags: review?(mrbkap)
Blocks: 720580
Comment on attachment 603836 [details] [diff] [review]
Only call FinishInitForWrappedGlobal when we just created a global. v1

Sorry, I should have seen this.

As a side note: since we're not doing DOM-agnostic anymore we might be able to simplify nsIScriptContext (and in particular its interaction with nsGlobalWindow::SetNewDocument). Might be worth a followup bug.
Attachment #603836 - Flags: review?(mrbkap) → review+
Pushed this to try: https://tbpl.mozilla.org/?tree=Try&rev=512e9b6ea22b

Updated

6 years ago
Blocks: 734029
Looks green enough. Pushed to m-i:

http://hg.mozilla.org/integration/mozilla-inbound/rev/7876e5486b51
Target Milestone: --- → mozilla13
(In reply to Bobby Holley (:bholley) from comment #8)
> http://hg.mozilla.org/integration/mozilla-inbound/rev/7876e5486b51

At least, this fixed this assertion for (m-3)
/tests/dom/tests/mochitest/whatwg/test_bug500328.html
Blocks: 731266
https://hg.mozilla.org/mozilla-central/rev/7876e5486b51
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1331344958.1331347862.11535.gz&fulltext=1
WINNT 5.2 comm-central-trunk debug test mochitests-3/5 on 2012/03/09 18:02:38

At least, this fixed this assertion for (m-3)
/tests/dom/tests/mochitest/whatwg/test_bug500328.html
/tests/dom/workers/test/test_suspend.html

V.Fixed
Severity: normal → major
Status: RESOLVED → VERIFIED
OS: Linux → All
Hardware: x86_64 → All
No longer blocks: 731266
You need to log in before you can comment on or make changes to this bug.