Closed
Bug 523769
Opened 15 years ago
Closed 15 years ago
Prevent IPC messages during GC
Categories
(Core Graveyard :: Plug-ins, defect, P1)
Tracking
(status1.9.2 .4-fixed)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
status1.9.2 | --- | .4-fixed |
People
(Reporter: bent.mozilla, Assigned: benjamin)
References
Details
(Whiteboard: [fixed-lorentz])
Attachments
(2 files)
See attached stack. Our 'plugin always wins' policy trips us up by allowing JS_Evaluate to run inside GC.
I think we'll have to set a GC callback to be notified when entering GC. And chain to the cycle collector.
Assignee | ||
Comment 1•15 years ago
|
||
Per IRC discussion, this is only an issue for NPClass.deallocate, and we should not be calling that during GC even in non-IPC situations... who knows what the plugin might be doing?
Reporter | ||
Updated•15 years ago
|
Assignee: nobody → bent.mozilla
Assignee | ||
Updated•15 years ago
|
Assignee: bent.mozilla → benjamin
Assignee | ||
Comment 2•15 years ago
|
||
Attachment #411190 -
Flags: review?(mrbkap)
Attachment #411190 -
Flags: review?(jst)
Assignee | ||
Updated•15 years ago
|
Priority: -- → P1
Assignee | ||
Updated•15 years ago
|
Whiteboard: [needs review jst/mrbkap]
Comment 3•15 years ago
|
||
Comment on attachment 411190 [details] [diff] [review]
Delayed-release of NPObject.deallocate, rev. 1
>diff --git a/js/src/xpconnect/idl/nsIJSRuntimeService.idl b/js/src/xpconnect/idl/nsIJSRuntimeService.idl
>+ [noscript, notxpcom] void registerGCCallback(in JSGCCallback func);
Because this can technically fail due to OOM, do we want to return a success code (or make this not notxpcom and throw if we fail, otherwise, if we do fail to add the callback, we're guaranteed to assert on shutdown.
>+ rtsvc->RegisterGCCallback(DelayedReleaseGCCallback);
>+
I see the RegisterGCCallback call, but no corresponding UnregisterGCCallback call. Is that intentional? If so, please comment.
This seems fine to me overall, though, so r=mrbkap.
Attachment #411190 -
Flags: review?(mrbkap) → review+
Assignee | ||
Comment 4•15 years ago
|
||
I don't think this can fail due to OOM: I'm pretty sure we'll abort. And yes, I didn't see any reason to unregister this gccallback, so I'll add a comment that it's ok to leave it present until shutdown.
Updated•15 years ago
|
Attachment #411190 -
Flags: review?(jst) → review+
Assignee | ||
Comment 5•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [needs review jst/mrbkap]
Comment 6•15 years ago
|
||
For what it's worth, the IID bump in http://hg.mozilla.org/mozilla-central/rev/785d2f84f4c4 is what broke http://dbaron.org/mozilla/leak-monitor/ on trunk. I can work around it, but I'm not sure if it's likely to break anything else.
Assignee | ||
Comment 7•15 years ago
|
||
http://hg.mozilla.org/projects/firefox-lorentz/rev/cc83dfcd5c84
http://hg.mozilla.org/projects/firefox-lorentz/rev/db261d9f0611 (undo incorrect UUID bump)
I used nsIJSRuntimeService_MOZILLA_1_9_2 on the branch to avoid interfaces changes there.
Assignee | ||
Comment 8•15 years ago
|
||
Oh, and that's just the xpconnect portion of the changes, the plugin bits will land in a bit with the other stuff from modules/plugin.
Assignee | ||
Comment 9•15 years ago
|
||
Whiteboard: [fixed-lorentz]
Comment 10•15 years ago
|
||
Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed
Assignee | ||
Comment 11•15 years ago
|
||
Merged into 1.9.2 at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/84ba4d805430
status1.9.2:
--- → .4-fixed
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•