Closed Bug 540868 Opened 14 years ago Closed 14 years ago

[OOPP] jsreftest leaked 12 instances of ChildNPObject

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: benjamin, Assigned: benjamin)

References

Details

Attachments

(3 files)

TEST-UNEXPECTED-FAIL | plugin process 3440 | automationutils.processLeakLog() | leaked 96 bytes during test execution
TEST-UNEXPECTED-FAIL | plugin process 3440 | automationutils.processLeakLog() | leaked 12 instances of ChildNPObject with size 8 bytes each (96 bytes total)

This is very likely to be Java, and hopefully not that hard to figure out. We're likely loading plugins by iterating over `window.java`, which loads the Java plugin.
This is a little complicated: I'm pretty sure Java is either creating cycles or is relying on the fact that the plugin host cleans up all the NPObjects when the instance is destroyed. The OOPP host currently doesn't do that: when the actors are destroyed, we release their NPObject, but we don't deallocate it.

I think I can fix this in ~PluginScriptableObject, although it might require special-casing "remote" NPObjects because the current PluginScriptableObjectChild::ScriptableDeallocate re-enters IPDL incorrectly in that case.
Assignee: nobody → benjamin
Attachment #422747 - Flags: review?(bent.mozilla)
Attachment #422747 - Flags: review?(bent.mozilla) → review+
Comment on attachment 422774 [details] [diff] [review]
Part 2, rev. 1: Leak fixup, track and clean up child NPObjects per-instance

+               "ScriptableDeallocate should have hanled this for proxies");

"handled"
Attachment #422774 - Flags: review?(bent.mozilla) → review+
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: