Closed
Bug 455765
Opened 16 years ago
Closed 16 years ago
TM: bad JIT interactions with Ubiquity [@ js_FastNewObject]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: shaver, Assigned: mrbkap)
References
Details
(Keywords: fixed1.9.1, meta)
Attachments
(1 file)
735 bytes,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
We've seen a few bugs where we crash with JIT enabled if Ubiquity is installed, but are OK if not. A quick conversation with Jono raised the possibility that it's related to evalInSandbox, which seems quite plausible to me given how that would give us unusual scope and global-object properties. Going to collect these cases under this bug so we can see if they are amenable to a systematic solution. (Making sure we don't trace under eIS might be a reasonable interim step?)
Flags: blocking1.9.1+
Comment 1•16 years ago
|
||
There is a parallel bug on file (crashing sunspider with ubiquity installed).
I indeed crash in SunSpider /w Ubiquity
Summary: TM: bad JIT interactions with Ubiquity → TM: bad JIT interactions with Ubiquity [@ js_FastNewObject]
Updated•16 years ago
|
Assignee: general → danderson
Assignee | ||
Comment 3•16 years ago
|
||
The problem here is that Ubiquity causes us to resolve the Window class way before we ever create a content window. This causes us to create a shared scriptable prototype (and all that fun stuff for it) from a place that doesn't funnel into nsXPConnect::InitClassesWithNewWrappedGlobal. That means that we create the JS class (but don't use it!) without the proper global flags. The easiest way to fix it is to notice this when we create the first instance of the window and set the global flags then. Note that we haven't created any instances of the object when we do this sneaky class manipulation!
Assignee: danderson → mrbkap
Status: NEW → ASSIGNED
Attachment #340480 -
Flags: superreview?(jst)
Attachment #340480 -
Flags: review?(jst)
Comment 4•16 years ago
|
||
Comment on attachment 340480 [details] [diff] [review] Proposed fix + if(isGlobal) + { + if(!(jsclazz->flags & JSCLASS_IS_GLOBAL)) + jsclazz->flags |= JSCLASS_GLOBAL_FLAGS; Here we could unconditionally set this bit and avoid the check, IMO. r+sr=jst, but please do add a comment explaining why this is needed.
Attachment #340480 -
Flags: superreview?(jst)
Attachment #340480 -
Flags: superreview+
Attachment #340480 -
Flags: review?(jst)
Attachment #340480 -
Flags: review+
Assignee | ||
Comment 5•16 years ago
|
||
Pushed as http://hg.mozilla.org/mozilla-central/rev/de88f8e08da9 (with a comment).
Assignee | ||
Updated•16 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Flags: in-testsuite-
Flags: in-litmus-
Updated•16 years ago
|
Keywords: fixed1.9.1
You need to log in
before you can comment on or make changes to this bug.
Description
•