Closed Bug 1004766 Opened 10 years ago Closed 10 years ago

[Unforgeable] attribute on a global leads to compartment mismatch during initialization

Categories

(Core :: DOM: Core & HTML, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla32

People

(Reporter: nsm, Assigned: bzbarsky)

References

Details

Attachments

(1 file)

Consider this -  http://codepad.org/cZT1SQIH & http://codepad.org/cMwDUhPM - when i remove [Unforgeable] on scope, no crash

From irc:
<bz_dinner> nsm: can you file and I'll take a look?
<bholley> nsm: so, the problem is that the Codegen is messing up and probably needs a JSAutoCompartment after the CreateGlobal call
<bholley> bz_dinner: ^
<nsm> i see other code already using unforgeable, what was special about this case?
<bz_dinner> yep
<bz_dinner> This is a globak
<bz_dinner> er, global
Flags: needinfo?(bzbarsky)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Flags: needinfo?(bzbarsky)
Comment on attachment 8416272 [details] [diff] [review]
Make sure to enter the compartment of our new global before working with it when wrapping global objects

Review of attachment 8416272 [details] [diff] [review]:
-----------------------------------------------------------------

Confirmed that it fixes the issue.
Attachment #8416272 - Flags: review?(nsm.nikhil) → review+
https://hg.mozilla.org/mozilla-central/rev/a4d2747c511a
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.