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

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

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):

https://bugzilla.mozilla.org/show_bug.cgi?id=128366

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

http://sourceforge.net/tracker/index.php?func=detail&aid=1280909&group_id=107955&atid=649116



Reproducible: Sometimes

Comment 1

[Simon Fraser [no longer active]]

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

sample firefox 10

and attach the resulting file.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

I've just released JEP 0.9.3+c:

http://javaplugin.sourceforge.net/

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

[Steven Michaud [:smichaud] (Retired)]

Attachment: 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

[Steven Michaud [:smichaud] (Retired)]

Attachment: Output from gdb's "thread apply all bt"

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Attachment: 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
(white).

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

[Steven Michaud [:smichaud] (Retired)]

Attachment: Output of gdb's "thread apply all bt" for Camino

Comment 7

[Simon Fraser [no longer active]]

So JEP 0.9.3+c fixes this?

Comment 8

[Steven Michaud [:smichaud] (Retired)]

> So JEP 0.9.3+c fixes this?

Yes, it does.

Comment 9

[Asa Dotzler [:asa]]

we want to get this on the trunk and then we'll consider it for beta2 if all
looks well.

Comment 10

[Josh Aas]

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

[Steven Michaud [:smichaud] (Retired)]

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

http://javaplugin.sourceforge.net/

Comment 12

[Asa Dotzler [:asa]]

please get the new version on the branch. thanks.

Comment 13

[Josh Aas]

JEP 0.9.4+a landed on branch and trunk.

Comment 14

[Samuel Sidler (old account; do not CC)]

Fixed on branch per comment 13.