290671 - Browser freezes when first Java applet after start is loaded from the web

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Java: OJI, defect)

Description

[Ciboman]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217

System configuration:
Mandrake 10.1, kernel 2.6.8.1-12mdksmp
Java Plugin from Linux JRE 1.5.0 (build 1.5.0-b64)
Mozilla: latest releases version 1.8b and 1.7.7

When a java applet is loaded from the local file system, everything works fine.
Also, when the first java applet was loaded from the local file system, and
afterwards a further java applet is loaded from the web, there is no problem
showing up.
Only, if the first java applet after the browser start is loaded from the web,
the browser freezes.

strace
When strace is started before the java applet is loaded from the web, the
browser won't crash.
When strace is started after the browser has crashed, it shows always the same
line containig a message "futex_wait".

Since the crash does not appear when the first applet was loaded from the local
filesystem, maybe it can be fixed by mozilla rather than by sun. Excuse my naive
approach, but why not initialize java to a state similar just like a loaded
applet would do it, if its preferences/advanced checkbox is enabled, maybe with
the start of an internal "dummy applet", just to avoid the crash?

The bug is annoying since it forces me to disable java support to avoid random
browser crashes on web sites running java applets.

Reproducible: Always

Steps to Reproduce:
1. Start mozilla with java enabled
2. Load an applet from the web
3. Watch mozilla freeze.

Actual Results:  
Browser freezes.

Expected Results:  
Run the java applet.

Comment 1

[Andrew Schultz]

Attachment: stacktrace from TB5146291Z

Comment 2

[Andrew Schultz]

Comment on attachment 180954 [details]
stacktrace from TB5146291Z

oops, wrong bug

Comment 3

[Andrew Schultz]

Can you get a stacktrace during the hang with gdb?
It sounds like timing is important, which would explain why loading locally or
strace-ing would fix it.

Comment 4

[Ciboman]

Attachment: Stacktrace of browsercrash (version 1)

Its the first time that I've used "gdb", so there may follow further versions
of the stacktrace if someone gives me advice how to get a better result.

Comment 5

[Andrew Schultz]

hmm.  I was hoping the stack would show the java plugin at the top, but it's not
there.  The stacktrace also shows a seg fault (crash) instead of a freeze/hang.

I assume you attached gdb after Mozilla was frozen.  At that point, you should
be able to do 'backtrace' to get a stack there, rather than continuing.

Comment 6

[Pete Zha]

mass reassign to Alfred

Comment 7

[molecularbiophysics]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1
java-1.4.2-sun-1.4.2.10

Important Notice: There is NO browser crash - Only temporary freezing.

1. Close all firefox windows and start firefox
2. Visit (any favorite java applet website) http://java.sun.com/applets/jdk/1.4/demo/applets/ArcTest/example1.html
3. While loading the java applet for the first time (in this session) the system CPU usage goes to _maximum. I can easily feel it as I have a _laptop_ and the CPU freq. is ramped UP immediately. The current firefox window is frozen (i.e) If you drag the window manager screen is garbled.
4. It needs to be understood _ONLY_ the current profile is affected.
5. If you have another profile running it is _NOT_ frozen.


The effect of _freezing_ is more when you are already browsing for sometime, example, 5 tabs open.

1. Open 5 websites (with NO java applets).
2. Now try opening http://java.sun.com/applets/jdk/1.4/demo/applets/ArcTest/example1.html
3. Now until the applet above loads, you _cannot_ switch tabs and temporarily the profile is frozen.

Important point: 
The freezing happens only when loading applet for the first time - for the profile - for the session. After loading this: 
 Go to http://java.sun.com/applets/jdk/1.4/index.html (or your favorite website) and load as many applets as you want. There is NO freezing, NO increase in CPU usage.

(As far as I know this problem does not happen in Windows XP.)

Comment 8

[Lucius Chiaraviglio]

Attachment: Stacktrace of Java hang when attempting to test Java under windbg

Not sure if this is related, but under Windows XP (SP3), Firefox 18.0.2 freezes when attempting to load Java (tried both a Live Map from www.nextbus.com and Oracle's own Java tester, http://www.java.com/en/download/testjava.jsp), but ONLY when running under windbg (which I was using to attempt to diagnose bug 690774) -- if Firefox is running outside of windbg and attempts to load Java, it usually works fine, and on the occasion that Java freezes, it is possible to close the offending tab and retry, because outside windbg Java does not freeze Firefox entirely.

Comment 9

[Benjamin Smedberg]

Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".

Comment 10

[Lucius Chiaraviglio]

Done -- new bug 841892