Summary: | Objective-C API: JSContext's dealloc causes ASSERT due to ordering of releases | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Mark Hahnenberg <mhahnenberg> | ||||
Component: | JavaScriptCore | Assignee: | Mark Hahnenberg <mhahnenberg> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | barraclough, ggaren, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Mark Hahnenberg
2013-01-25 12:49:17 PST
This is a bug in C API. We need to add the Identifier table save/restore in JSContextGroupRelease. Created attachment 185578 [details]
Patch
Committed r141321: <http://trac.webkit.org/changeset/141321> + JSLockHolder lock(globalData); I don't think this is valid -- you'll end up unlocking the lock after you've deallocated the JSGlobalData. I think you can just eliminate the lock and rely on thread-safe refcounting. (In reply to comment #5) > + JSLockHolder lock(globalData); > > I don't think this is valid -- you'll end up unlocking the lock after you've deallocated the JSGlobalData. I think you can just eliminate the lock and rely on thread-safe refcounting. JSLockHolder refs the JSGlobalData when it locks it, so it will only be destroyed after the lock has released the JSGlobalData. I think you're right that we don't need the lock though. I was just trying to replicate what JSGlobalContextRelease does. > JSLockHolder refs the JSGlobalData when it locks it, so it will only be destroyed after the lock has released the JSGlobalData.
Cool cool.
|