741778 - Pasting image into photo editor http://pixlr.com/editor/ with Java then closing Firefox leaks firefox.exe in memory while java.exe is not killed manually

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Loic]

Attachment: clipboard_read_only_java_dialog_box.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120402 Firefox/14.0a1
Build ID: 20120402031127

Steps to reproduce:

STR:
0) Be sure the plugin Java is enabled
1) Press Print Screen key (or copy a random image)
2) Open http://pixlr.com/editor/ in a new tab
3) Click on the menu 'Create a new image'
4) Click on the button 'OK' of the dialog box 'New image'
5) Go to the menu 'Edit' then select 'Paste' (or Ctrl+V)

NB: tested with plugin Java(TM) Platform SE 6 U31 6.0.310.5


Actual results:

1) http://pixlr.com/editor/ loads indefinitely the image from the clipboard and fails to paste it.

2) If you close the tab, it stays alive (see about:memory or about:compartments).
Memory log:
│  ├─────318,216 B (00.39%) -- compartment(http://pixlr.com/editor/)
│  │     ├──159,744 B (00.20%) -- gc-heap
│  │     │  ├──120,920 B (00.15%) -- arena
│  │     │  │  ├──119,976 B (00.15%) ── unused
│  │     │  │  ├──────624 B (00.00%) ── headers
│  │     │  │  └──────320 B (00.00%) ── padding
│  │     │  ├───25,592 B (00.03%) -- shapes
│  │     │  │   ├──14,832 B (00.02%) ── dict
│  │     │  │   ├───7,616 B (00.01%) ── base
│  │     │  │   └───3,144 B (00.00%) ── tree
│  │     │  ├───12,176 B (00.01%) -- objects
│  │     │  │   ├──10,720 B (00.01%) ── function
│  │     │  │   └───1,456 B (00.00%) ── non-function
│  │     │  ├──────768 B (00.00%) ── type-objects
│  │     │  └──────288 B (00.00%) ── scripts
│  │     ├──131,072 B (00.16%) -- mjit
│  │     │  └──131,072 B (00.16%) ── code
│  │     ├───19,872 B (00.02%) -- shapes-extra
│  │     │   ├──12,864 B (00.02%) ── compartment-tables
│  │     │   ├───6,592 B (00.01%) ── dict-tables
│  │     │   ├─────288 B (00.00%) ── tree-tables
│  │     │   └─────128 B (00.00%) ── tree-shape-kids
│  │     ├────6,912 B (00.01%) -- objects
│  │     │    ├──6,784 B (00.01%) ── slots
│  │     │    └────128 B (00.00%) ── misc
│  │     ├──────544 B (00.00%) -- type-inference
│  │     │      └──544 B (00.00%) ── tables
│  │     └───────72 B (00.00%) ── script-data

3) If you close Firefox, firefox.exe stays in memory while you don't kill java.exe (Java Platform SE binary) manually.


Expected results:

http://pixlr.com/editor/ should display a Java security dialog box about allowing the application to read only the clipboard (see my attachment), then paste the image in the box 'Untitled'.
And of course no memory leak should happen.

FF 11 & 12 are not affected.
FF 13 & 14 are affected.

Comment 1

[Justin Lebar (not reading bugmail)]

If this is actually a regression, that's quite interesting.

Comment 2

[Justin Lebar (not reading bugmail)]

I don't see the zombie compartment, although the page does apparently loop infinitely and hang my browser.  But from

> 3) If you close Firefox, firefox.exe stays in memory while you don't kill java.exe (Java Platform SE 
> binary) manually.

it sounds like java may be doing something very dumb here.

Comment 3

[Loic]

(In reply to Justin Lebar [:jlebar] from comment #1)
> If this is actually a regression, that's quite interesting.

Yes, it's a 1-month regression indeed. I worked on mozregression and here the results:

m-c:
good=2012-02-29
bad=2012-03-01
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=30b4f99a137c&tochange=1c3b291d0830

m-i:
good=2012-02-28
bad=2012-02-29
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=eac2ff42164d&tochange=bff447521a33

Changelogs are pretty huge, and I'm not really good at find the culprit patch.
Maybe this one but it needs to be confirmed:
Bug 406541 - Ensure we agree with java on applet codebase, and run security checks for file: codebase
(access denied for me)

In reply to Justin Lebar [:jlebar] from comment #2)
> I don't see the zombie compartment, although the page does apparently loop
> infinitely and hang my browser. 
On Win 7, firefox.exe stays in memory while java.exe isn't killed.
I tested on Win XP, firefox.exe quits properly and java.exe too.
In both cases the image is not pasted.
So I guess it's a mix between freeze and memory leak depending on the machine/OS.

Comment 4

[Justin Lebar (not reading bugmail)]

> Changelogs are pretty huge, and I'm not really good at find the culprit patch.

That's a good guess!  Someone needs to prove it by checking before and after that change.

Comment 5

[Loic]

I see this warning in the Web console just after pasting the image, I'm not sure if it's relevant:

Timestamp: 03/04/2012 22:39:54
Warning: The character encoding of a framed document was not declared. The document may appear different if viewed without the document framing it.
Source File: http://pixlr.com/editor/clipboard.htm
Line: 0

Comment 6

[John Schoenick [:johns]]

I'm looking into this in conjunction with a refactoring of a lot of Java/plugin loading code

Comment 7

[Jet Villegas (inactive)]

P2 per Memshrink

Comment 8

[John Schoenick [:johns]]

The culprit was backed out of aurora so this should only 14+ now

http://hg.mozilla.org/releases/mozilla-aurora/rev/96a1b7f055c9

Comment 9

[Loic]

Another simple testcase:
http://gotnarcosis.com/brucewittmeier/technical/TruckTrailerScale.html

The Java applet fails to run and the Java console logs these errors:

charger : classe TruckTrailerScale.class introuvable.
java.lang.ClassNotFoundException: TruckTrailerScale.class
	at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Exception : java.lang.ClassNotFoundException: TruckTrailerScale.class

Comment 10

[Alex Keybl [:akeybl]]

(In reply to John Schoenick [:johns] from comment #8)
> The culprit was backed out of aurora so this should only 14+ now
> 
> http://hg.mozilla.org/releases/mozilla-aurora/rev/96a1b7f055c9

As with bug 736965, can we back this out in FF14 or should we consider taking a forward fix?

Comment 11

[John Schoenick [:johns]]

Bug 406541 was backed out of 14 as well:
http://hg.mozilla.org/releases/mozilla-beta/rev/4782adb17edf

Bug 745030 will be the proper fix for 406451 regressions. I had hoped to land in 15, but is now looking more involved. I'll know by the end of next week if it will be landing on 16 - If not, I can back 406541 out of trunk along with 15 and reland it when the fix is ready

The interface change is only removing one function that's likely not of interest to addons. The 15+ backout can use 14's UUID

Comment 12

[John Schoenick [:johns]]

Bug 406541 has been backed out of all branches, so this regression should be no more

Comment 13

[Loic]

Indeeed I tried with FF14, the regression is gone after the backout.