Opened 12 years ago
Closed 12 years ago
#1092 closed defect (fixed)
Crash saving games in debug-mode: Compartment mismatch
Reported by: | Yves | Owned by: | Yves |
---|---|---|---|
Priority: | Should Have | Milestone: | Alpha 9 |
Component: | Core engine | Keywords: | |
Cc: | Yves | Patch: |
Description
When saving a game in debug-mode it crashes. Apparently the reason is that SavedGames::Save tries calling "SetProperty" with a value returned by the GUI's scriptinterface using it's own instance of scriptinterface (simulation.GetScriptInterface()).
simulation.GetScriptInterface().SetProperty(metadata.get(), "gui", gui->GetSavedGameData());
Each scriptinterface uses its own Spidermonkey runtime with an own compartment. the Value returned by gui->GetSavedGameData() "contains" another compartment than the one contained in the scriptinterface object of simulation. Spidermonkey checks if they match and raises an exception in debug mode because they don't.
In release mode everything seems to work fine, but there are probably some hidden problems there too because the compartments don't match either.
According to the Spidermonkey documentation objects of one compartment can't be used in another one by default, but there seem to be ways to interchange objects between compartments. I've started looking into spidermonkey a few hours ago, so I don't yet fully understand it. I'll need a bit more time before I know more details and what an appropriate solution would be.
Attachments (1)
Change History (6)
by , 12 years ago
Attachment: | callstack_compartment_mismatch.txt added |
---|
comment:1 by , 12 years ago
Cc: | added |
---|---|
Milestone: | Backlog → Alpha 9 |
Owner: | set to |
Status: | new → assigned |
comment:2 by , 12 years ago
I'm pretty sure you need to use
JSAutoEnterCompartment ac; if (!ac.enter(cx, obj)) return JS_FALSE;
where obj potentially resides in a different compartment than cx.
comment:3 by , 12 years ago
Furthermore, if you need to use an object from one compartment in another, you can use JS_WrapValue/JS_WrapObject.
comment:4 by , 12 years ago
Oops, I should have tested that better... In this case the objects aren't just in different compartments, they're in different JSRuntime
s, so there's no way to share the data - need to clone it into the right runtime/context before using it.
comment:5 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
the callstack after it crashes...