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

RESOLVED FIXED

Status

()

Core
Plug-ins
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Loic, Assigned: johns)

Tracking

({regression})

unspecified
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox13+ unaffected, firefox14+ unaffected, firefox15+ unaffected, firefox16+ unaffected)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 611798 [details]
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.
(Reporter)

Updated

5 years ago
Blocks: 668871
Whiteboard: [MemShrink]
If this is actually a regression, that's quite interesting.
Keywords: regression, regressionwindow-wanted
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.
(Reporter)

Comment 3

5 years ago
(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.
(Reporter)

Updated

5 years ago
Keywords: regressionwindow-wanted
> 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.
(Reporter)

Comment 5

5 years ago
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
(Assignee)

Updated

5 years ago
Assignee: nobody → jschoenick
(Assignee)

Comment 6

5 years ago
I'm looking into this in conjunction with a refactoring of a lot of Java/plugin loading code
(Assignee)

Updated

5 years ago
tracking-firefox13: --- → ?
tracking-firefox14: --- → ?

Comment 7

5 years ago
P2 per Memshrink
Whiteboard: [MemShrink] → [MemShrink:P2]

Updated

5 years ago
tracking-firefox13: ? → +
tracking-firefox14: ? → +
(Assignee)

Updated

5 years ago
Depends on: 745030
(Assignee)

Updated

5 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Assignee)

Updated

5 years ago
Assignee: jschoenick → nobody
Component: Untriaged → Plug-ins
OS: Windows 7 → All
Product: Firefox → Core
QA Contact: untriaged → plugins
Hardware: x86_64 → All
(Assignee)

Updated

5 years ago
Assignee: nobody → jschoenick
(Assignee)

Comment 8

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

http://hg.mozilla.org/releases/mozilla-aurora/rev/96a1b7f055c9
status-firefox13: --- → unaffected
status-firefox14: --- → affected
Version: 13 Branch → 14 Branch
(Reporter)

Comment 9

5 years ago
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
(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?
(Assignee)

Comment 11

5 years ago
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
status-firefox14: affected → unaffected
status-firefox15: --- → affected
status-firefox16: --- → affected
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
Version: 14 Branch → 15 Branch

Updated

5 years ago
tracking-firefox15: ? → +
tracking-firefox16: ? → +
(Assignee)

Comment 12

5 years ago
Bug 406541 has been backed out of all branches, so this regression should be no more
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
status-firefox15: affected → unaffected
status-firefox16: affected → unaffected
Resolution: --- → FIXED
Version: 15 Branch → unspecified
(Reporter)

Comment 13

5 years ago
Indeeed I tried with FF14, the regression is gone after the backout.
You need to log in before you can comment on or make changes to this bug.