396368 - JS LiveConnect usage leaks

Status: RESOLVED INVALID

(Core Graveyard :: Java: OJI, defect, P4)

Description

[Robert Sayre]

The Java plugin on www.showmyip.com causes us to leak quite a bit.

Comment 1

[Robert Sayre]

Attachment: nsJVManager balance tree

Comment 2

[Boris Zbarsky [:bzbarsky]]

Over to right component.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So it looks to me like on Mac (where Robert is) we must be leaking an MRJPlugin, which leaks the JVMManager...  I'd be interested in a balance tree for the MRJPlugin.

At first blush, though, this looks like a refcount cycle between the MRJPlugin (which getService()s the JVM manager into a member) and the JVMManager (which sticks the return of nsPluginHostImpl::GetPluginFactory into a member).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Nevermind about balance tree; MRJPlugin doesn't log its addref and release.  I stand by my comment about a reference cycle.

That said, we leak on Linux too, with similar stacks, so there may be similar issues there.  But that code doesn't even live in our tree...

Comment 5

[Robert Sayre]

Attachment: A java.net.Inet4Address left in the JS heap

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: This _might_ help with the MRJ leak. It doesn't help the Linux one....

Comment 7

[Robert Sayre]

(In reply to comment #6)
> Created an attachment (id=281123) [details]
> This _might_ help with the MRJ leak.  It doesn't help the Linux one....
> 

nope, doesn't help on mac either

Comment 8

[Boris Zbarsky [:bzbarsky]]

Does the balance tree for nsJVMManager still look the same?

I wonder whether there's a way to build with the in-tree MRJ so we could add refcount logging to it and see what leaks it.

Comment 9

[Robert Sayre]

Attachment: bloat diff

After trying again today, it looks like attachment 281123 [details] [diff] [review] did work a bit.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #8)

> I wonder whether there's a way to build with the in-tree MRJ so we
> could add refcount logging to it and see what leaks it.

Not really.

But you could rebuild the MRJ Plugin JEP that comes with the Java
Embedding Plugin -- which was based on the in-tree MRJ Plugin Carbon.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Hmm.  That diff shows nsJVMManager as "went away", not "fixed-leaks"??

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

How much memory are we leaking here? If it's not a lot we might let this one slip and hope it gets fixed when liveconnect goes away. Additionally, is this happening on a lot of java pages, or have we only found one so far?

Robert: Could you try to figure out who's responsible for the leak here? If it's us and the leak is bad we need to find an owner.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> How much memory are we leaking here?

This particular test leaks at least everything on the page (windows, document, stylesheets, DOM tree, etc).

Comment 14

[Robert Sayre]

Attachment: small testcase

Comment 15

[Robert Sayre]

nsCycleCollector: nsGlobalWindow 0x3691177c was not collected due to 1
  external references (2 total - 1 known)
  An object expected to be garbage could be reached from it by the path:
    nsGlobalWindow 0x3691177c
  The 1 known references to it were from:
    XPCWrappedNative (Window) 0x369124a0
nsCycleCollector: nsGlobalWindow 0x36346cbc was not collected due to 1
  external references (2 total - 1 known)
  An object expected to be garbage could be reached from it by the path:
    nsGlobalWindow 0x36346cbc
  The 1 known references to it were from:
    XPCWrappedNative (Window) 0x36347b60
nsCycleCollector: XPCWrappedNative (Window) 0x369124a0 was not collected due to 1
  external references (1 total - 0 known)
  An object expected to be garbage could be reached from it by the path:
    XPCWrappedNative (Window) 0x369124a0
    nsGlobalWindow 0x3691177c
  The 0 known references to it were from:
nsCycleCollector: XPCWrappedNative (Window) 0x36347b60 was not collected due to 1
  external references (1 total - 0 known)
  An object expected to be garbage could be reached from it by the path:
    XPCWrappedNative (Window) 0x36347b60
    nsGlobalWindow 0x36346cbc
  The 0 known references to it were from:

Comment 16

[Robert Sayre]

Attachment: reduced

calling any LiveConnect-wrapped Java method causes a leak. 

I'll add a JS heap that shows LiveConnect Java methods still in the JS heap. These are rooted in jsj_ResolveExplicitMethod and add_java_method_to_class_descriptor.

Comment 17

[Robert Sayre]

Attachment: JS heap at shutdown

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Would still be nice to have this fixed, but what with liveconnect going away and all there are more important leaks.

Comment 19

[Mike Schroepfer]

Given comment 18 taking this off blocking list

Comment 20

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Sick of seeing this in my kw:mlk kw:testcase query.