Script caching in messageManager leaks

RESOLVED FIXED in mozilla2.0b4

Status

()

defect
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: azakai, Assigned: smaug)

Tracking

Trunk
mozilla2.0b4
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+, fennec2.0a1+)

Details

Attachments

(2 attachments)

When using script caching as in bug 584866, an intermittent leak occurs. This apparently is caused by the scripts not being freed, while they hold on to the scripts' global objects and possibly other things.

The leak does not always happen - might depend on timing issues of when cycle collection is run. But without script caching, the leak never occurs.
Blocks: 550936
nsCycleCollector: JS Object (Script - chrome://mozapps/content/extensions/extensions-cont (global=7fffdcc1ae58) 0x7fffdcc20c18 was not collected due to 
  external references
  An object expected to be garbage could be reached from it by the path:
    JS Object (Script - chrome://mozapps/content/extensions/extensions-cont (global=7fffdcc1ae58) 0x7fffdcc20c18
        via parent
    JS Object (ContentFrameMessageManager) (global=7fffdcc1ae58) 0x7fffdcc1ae58
        via InstallTriggerManager
    JS Object (Function - InstallTriggerManager) (global=7fffdcc1ae58) 0x7fffdcc20ca8
        via prototype
    JS Object (Object) (global=7fffdcc1ae58) 0x7fffdcc2c4c8
        via installerIds
    JS Object (Array) (global=7fffdcc1ae58) 0x7fffdcc2c510
        via dense_array_elems
    JS Object (Object) (global=7fffdcc1ae58) 0x7fffd74c5b88
        via window
    XPCNativeWrapper (Window) (global=7fffdcc46dc8) 0x7fffdcc55240
        via wrappedNative.flatJSObject
    JS Object (Window) (global=7fffdcc46dc8) 0x7fffdcc46dc8
        via xpc_GetJSPrivate(obj)
    XPCWrappedNative (Window) 0x7fffdb324e00
        via <unknown edge>
    nsGlobalWindow 0x7fffdb40fc68
  The known references to it were from:
    JS Object (Script - chrome://mozapps/content/extensions/extensions-cont (global=7fffdcc1ae58) 0x7fffdcc20c18 via object



The nsLayoutStatics::Shutdown is never called because the cached scripts hold references to the global object which in turn hold references to the world.

Because nsLayoutStatics::Shutdown is never called, the ::Shutdown method in the frame manager is never called.  And, the cache scripts are never unrooted.

We could force this by having a new event -- maybe xpcom-shutdown -- to clear all of the cached scripts?
Attachment #465910 - Flags: review?(Olli.Pettay)
Comment on attachment 465910 [details] [diff] [review]
patch v.1 - wip?

Could we add a simple helper class which is the observer and calls
nsFrameScriptExecutor::Shutdown().
And only add the observer when the first nsFrameScriptExecutor is created


The patch would cause all the nsFrameMessageManager objects to stay alive until
nsIObserverService shuts down.
Attachment #465910 - Flags: review?(Olli.Pettay) → review-
olli, i am out of the office most of today.  could you whip something up?
Posted patch patch v.2Splinter Review
Attachment #466188 - Flags: review?(Olli.Pettay)
Attachment #466188 - Flags: review?(Olli.Pettay) → review+
blocking2.0: --- → ?
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0a1+
http://hg.mozilla.org/mozilla-central/rev/8541ae9ea9b3
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b4
blocking2.0: ? → final+
You need to log in before you can comment on or make changes to this bug.