Closed Bug 455765 Opened 16 years ago Closed 16 years ago

TM: bad JIT interactions with Ubiquity [@ js_FastNewObject]

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: shaver, Assigned: mrbkap)

References

Details

(Keywords: fixed1.9.1, meta)

Attachments

(1 file)

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+
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]
Assignee: general → danderson
Attached patch Proposed fixSplinter Review
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 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+
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Depends on: 460790
Flags: in-testsuite-
Flags: in-litmus-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: