Closed Bug 523769 Opened 15 years ago Closed 15 years ago

Prevent IPC messages during GC

Categories

(Core Graveyard :: Plug-ins, defect, P1)

x86
All
defect

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)

Attached file Stack (deleted) —
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.
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?
Blocks: 523094
Component: IPC → Plug-ins
QA Contact: ipc → plugins
Assignee: nobody → bent.mozilla
Assignee: bent.mozilla → benjamin
Attachment #411190 - Flags: review?(mrbkap)
Attachment #411190 - Flags: review?(jst)
Priority: -- → P1
Whiteboard: [needs review jst/mrbkap]
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+
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.
Attachment #411190 - Flags: review?(jst) → review+
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [needs review jst/mrbkap]
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.
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.
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.
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: