Occasional hangs loading first Java applet (with recent trunk builds and the JEP)




12 years ago
12 years ago


(Reporter: smichaud, Assigned: Josh Aas)



Mac OS X
Bug Flags:
blocking1.8b4 -
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)




(4 attachments)



12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050902 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050902 Firefox/1.0+

Recent versions of Firefox (for example DeerPark Alpha 2) and Camino
(for example Camino 0.9a2) sometimes hang as you're trying to load a
Java applet for the first time in a given browser session. (These
hangs actually take place as part of the Java Virtual Machine (the
"AWT libraries") is being loaded (which happens the first time you
load an applet in a given browser session).)

The hangs are most likely to occur on applets that take a long time to
load -- such as the NOAA radar looping applets.

Older Mozilla-family browsers (e.g. Firefox 1.0.X, Camino 0.8.X and
Mozilla 1.7.X) aren't effected.

This problem is caused by one or more Apple bugs. I'm about to release
a Java Embedding Plugin "nightly" (0.9.3+c) that works around them. I
hope to get it quickly landed on the trunk and (especially) the 1.8
branch, so that it will be included in Firefox 1.5 Beta 1 when that
comes out next week.

If you use gdb to "break into" a browser process that has experienced
one of these hangs, you will notice that a secondary thread is stuck
in JNI_OnLoad() (in libawt.jnilib). The Java Embedding Plugin has long
contained workarounds for _other_ Apple bugs/design-flaws that cause
hangs in JNI_OnLoad(). The "new" bug (or bugs) have existed for a long
time, but seem to have been triggered by recent changes in the
Mozilla-family browsers (probably the "fix" for Mozilla bug 128366,
which started loading the MRJPlugin.plugin on demand):


This same bug has also been filed at the Java Embedding Plugin's Bugs


Reproducible: Sometimes


12 years ago
Ever confirmed: true
Flags: blocking1.8b4?

Comment 1

12 years ago
When it hangs, please run 'sample' for, say, 10 seconds like:

sample firefox 10

and attach the resulting file.

Comment 2

12 years ago
I've just released JEP 0.9.3+c:


Please test it before deciding whether or not to land it on the 1.8 branch
before Firefox 1.5 Beta 1 is released.

I do realize that it's risky to make non-trivial changes so close to the
release date.  But I've tested JEP 0.9.3+c quite thoroughly.  And the problems
that it fixes are rather nasty.


Comment 3

12 years ago
Created attachment 194767 [details]
Output from "sample firefox 10"

> When it hangs, please run 'sample' for, say, 10 seconds like:
> sample firefox 10
> and attach the resulting file.

I'm not sure why you want this, but here it is.  (I used Deer Park
Alpha 2 and JEP 0.9.3+b on OS X 10.4.2).

By the way, the "hangs" I'm talking about don't actually block (or
fully block) the main thread.  NSEvents (and CFRunLoop input sources)
continue to be processed in the kCFRunLoopDefaultMode mode.  But the
WaitNextEvent loop in the browser is blocked.  So, though you have
access to the menu, you can't do anything to the current window except
close it (and when you do close it (directly or by quitting the
browser) you get a crash).

This NSEvent (and CFRunLoop) event processing takes place (on the main
thread) in the loop starting at line 983 (in the current, 0.9.3+c
version) of AppletView.m, in AppletView maybeCreateJavaVM.

(By the way, I notice that "sample" only seems interested in what's
happening on the main thread.  So it misses the actual cause of the
"hang".  I'll also append the output of "thread apply all bt" in gdb
from inside the "hung" process.)

Comment 4

12 years ago
Created attachment 194768 [details]
Output from gdb's "thread apply all bt"

Comment 5

12 years ago
Created attachment 194772 [details]
Output of "sample Camino 10"

In for a penny, in for a pound :-)

Here's the result of running "sample Camino 10" using Camino 0.9a2
with JEP 0.9.3+b on OS X 10.3.9 (I couldn't seem to get the hang to
happen in OS X 10.4.2).

Once again the main thread isn't (fully) blocked.  And though some
kind of event loop in the browser clearly _is_ blocked, it isn't
(can't be) the WaitNextEvent loop.  The visible symptoms are also
slightly different than with Deer Park:  You can move the browser
window around (in which the "hang" has occurred), and you can resize
it.  But when you do resize the window it goes completely blank

As with Deer Park, the menu is still accessible.  And (on Panther and
Jaguar, but not Tiger) opening the menu breaks you out of the hang --
whether you're using Deer Park or Camino.

Comment 6

12 years ago
Created attachment 194773 [details]
Output of gdb's "thread apply all bt" for Camino

Comment 7

12 years ago
So JEP 0.9.3+c fixes this?

Comment 8

12 years ago
> So JEP 0.9.3+c fixes this?

Yes, it does.

Comment 9

12 years ago
we want to get this on the trunk and then we'll consider it for beta2 if all
looks well.
Flags: blocking1.8b5+
Flags: blocking1.8b4?
Flags: blocking1.8b4-

Comment 10

12 years ago
JEP update that should fix this bug was landed on the trunk - leaving this bug
open for a branch landing if things work out

Comment 11

12 years ago
The fix for this is now incorporated in version 0.9.4 of the Java Embedding
Plugin, which I've just released:


Comment 12

12 years ago
please get the new version on the branch. thanks.
Assignee: nobody → joshmoz

Comment 13

12 years ago
JEP 0.9.4+a landed on branch and trunk.
Last Resolved: 12 years ago
Resolution: --- → FIXED
Fixed on branch per comment 13.
Keywords: fixed1.8
You need to log in before you can comment on or make changes to this bug.