Closed Bug 307757 Opened 19 years ago Closed 17 years ago

Java on Firefox 1.5 beta sometimes uses 85% cpu even after closing applet and sometimes crashes [@ CoreGraphics.203.30.0 + (00071cd8)]

Categories

(Core Graveyard :: Java: OJI, defect)

Product:
Core Graveyard
Component:
Java: OJI
Version:
1.8 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: docbill+bugzilla, Assigned: alfred.peng)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

When opening an applet, such as the one above, my whole machine slows down to a
crawl.  It remains slow, even when the applet is idling, and after the applet
has been closed.  The only way I have found to recover is to close Firefox.  

This only happens in the new firefox.

Reproducible: Always

Steps to Reproduce:
1. Open the URL
http://javadjvu.foxtrottechnologies.com/cgi-bin/djvuapplet.pl/examples/encyclopediabrit26ed11arch.djvu?zoom=width
2. Try and do something.
3.

Actual Results:  
The applet is extremely slow, as well as the rest of the machine until firefox
is closed.  (The applet is never unloaded, even after closing the window.)

Expected Results:  
Performance should be the same as Safari, which uses the same version of Java. 
The applet should unload when the page is closed.  When the applet is idling,
virtually no CPU time should be used.
I'm not able to reproduce what you report.

This applet is a terrible CPU hog on every platform and in every browser that
I tried -- including Safari.  And I didn't notice any significant differences
in how it behaved in Safari and in Firefox 1.5 Beta 1.  My Mac tests were done
on OS X 10.3.9.  The other tests were of Firefox 1.0.6 on SuSE Linux 9.2
(using Sun's Java 1.4.2_08), and of Firefox 1.0.6 and Internet Explorer 6.0 on
Windows XP Pro with all the current updates (using Sun's Java 1.5.0_02).

In all of my tests the applet failed to scroll smoothly -- when you try to
scroll it, it temporarily always uses 100% of the CPU.  In both Safari and
Firefox 1.5 Beta 1, if you leave the applet alone, it fairly quickly falls
back to alternating between using about 25% of the CPU and using 2% or 3%.  In
both browsers, it seems to make no difference if you minimize the browser
window or leave it "open".  In both browsers, closing the window that contains
the applet (so that no other browser windows are open) makes the CPU usage
fall to around 0% after a few seconds.

> after the applet has been closed

What do you mean by this?
Assignee: nobody → yuanyi21
Component: General → Java: OJI
Product: Firefox → Core
QA Contact: general → oji
Version: unspecified → 1.8 Branch
(In response to the change in this bug's "Product" and "Component" fields --
from "Firefox" to "Core" and from "General" to "Java: OJI".)

I don't think these changes are incorrect.  But I want to emphasize that the
problem(s) reported here seem to be caused by the applet that the "URL" loads,
not by any Mozilla.org (or Java Embedding Plugin) code or by any particular
JVM.


It does sound like you are not reproducing the bug.  Strangely, I reproduced
three  times in a row yesterday, after the problem was reported to me by someone
else on a different machine.  But today CPU performance is normal, as you
described.  When I say 100%, I mean it didn't drop below 85% ever, until I quit
firefox.


However, the applet is still not unloading.  The way I can tell is by looking at
the memory usage in the in the java console.  Wait until the applet is done
producing messages, and then press "g" in the console window.  Do that a couple
of times.  Then close the browser window with the applet.  Press "g" a few more
times.  If the applet is unloaded, the free amount of memory should reach nearly
the same value as total memory.  I believe the difference should actually be
about 3 MB, because the console takes some memory and there is some static
storage.  Instead, you will find the memory usage barely changes after closing
the window.  This indicates the applet is still resident in memory.

If you repeat the above tests several times, you will find each time the memory
use increases.  I found I have about a 10% chance of crashing firefox by closing
the window.

Bill

TB9216933K
It took 8 tries today, but the same problem finally happened again.  This time
however, I see CPU usage did drop as low as 65% after I closed the applet
window, but the average CPU usage remained above 85%.

Bill
BTW.  The problem is definitely not the applet.  Firefox 1.5 beta 1 on MacOSX is
the only platform that has produced this problem.  Firefox 1.0.6 produces other
problems which have been fixed the the new core, but not the 100% cpu forever bug.

Chances are it is a combination of problems.  For example, the MacOSX versions
of Java do different locking than Sun Java.  This has been known to cause
deadlocks.  It can well be that one browser has a deadlock while another doesn't
running the same code and same version of java just because the timing is
different.  This does not look like a deadlock issue, but it could be s
What version (or versions) of OS X are you using?

And please attach your own stack trace(s) here for crashes that you've
experienced.  (I looked at the entry for the Talkback ID posted in comment #4,
but it's "Stack Signature" link points to a stack trace for some other
problem.)


(In reply to comment #7)
> What version (or versions) of OS X are you using?
10.3.9

> And please attach your own stack trace(s) here for crashes that you've
> experienced.  (I looked at the entry for the Talkback ID posted in comment #4,
> but it's "Stack Signature" link points to a stack trace for some other
> problem.)

I don't know how to do that.  TB9216933K is the crash I mentioned in comment #3.
 I can't say if it is related to this problem or not, other than the crash
occured while trying to report on the applet unloading portion of the problem. 
I am suspecting that this version of firefox is not setting the top level thread
group for the applet, which would explain it not unloading.  If so, then it
would also be a security problem.  But lets wait until someone who understands
the mozilla code looks into it before making any such conclusions.

Bill

> 
> 


> the applet is still not unloading

The applet definitely _does_ "unload" when you close the window that contains
it (at least it does in all my tests).  But Java does its own memory
management, so "unloading" an applet has only an indirect effect on RAM usage.

There are several parameters you can use (in the Java control panel's "Java
Runtime Parameters" box) to make the Java Embedding Plugin write debugging
information to the Java Console.  One of them is "jep.debug.release".  To turn
it on, add "-Djep.debug.release=true" (without the quotes, of course) to the
Java Runtime Parameters box.  (You'll also (of course) need to quit the
browser and restart it, if it's currently running.)

You'll see (or should see) up to four different kinds of entries for the
different stages of "releasing" an applet's resources.  All four different
kinds should appear for each applet in a window when you close that window.
Here's an example (generated by closing a window containing the applet loaded
by your URL, using Firefox 1.5 Beta 1 on OS X 10.3.9):

Sat Sep 10 13:48:33 CDT 2005 AppletHolder.destroyApplet() for DjVuApplet
2005-09-10 13:48:34 -0500 CAppletWindow:cleanup for DjVuApplet
2005-09-10 13:48:34 -0500 JEPController:dealloc for DjVuApplet
2005-09-10 13:48:34 -0500 AppletView:dealloc for DjVuApplet

The first log entry appears just after the browser has made a call to
nsIPluginInstance::Destroy() for the applet in question.  The second appears
after the applet's own destroy() method has been called, and dispose() has
been called on the applet's AppletHolder() (also called an "applet viewer").
The third appears when the JEPController object corresponding to an applet is
deallocated.  The fourth appears when the AppletView object corresponding to
an applet is deallocated.  When/if all four log entries appear, everything has
been done that _can_ be done to explicitly release an applet's resources.

If you don't see all four entries after closing a window (one for each applet
in a window), I suspect that the browser has hung (or crashed) while the
window was being closed.  This would also explain why CPU usage sometimes
stays high after closing an window with your applet in it.

> The way I can tell is by looking at the memory usage in the in the java
> console.

I haven't yet tried this, but I'll bet you get exactly the same results in
Safari.


> I am suspecting that this version of firefox is not setting the top level
> thread group for the applet, which would explain it not unloading.

No.  You can see this for yourself by pressing 't' in the Java Console (which
displays a "thread list" -- your applet has its own group.


>> And please attach your own stack trace(s) here for crashes that you've
>> experienced.  (I looked at the entry for the Talkback ID posted in comment
>> #4, but it's "Stack Signature" link points to a stack trace for some other
>> problem.)
>
>I don't know how to do that.

It's Apple's own stack trace(s) that I'm after.  Whenever a crash occurs that
Apple's "crashreporterd" is able to catch, it appends an entry for the crash
to a file in (usually) ~/Library/Logs/CrashReporter/ (i.e. in the
Library/Logs/CrashReporter/ directory under your home directory).  In the case
of Firefox (or DeerPark) that file is usually (always?)
"firefox-bin.crash.log".

I don't want the whole file -- which can be quite large, depending on how
often Firefox crashes :-)  I just want the specific entries for the crash(es)
relevant to this bug.  Copy those entries to seperate files (one per crash),
and attach them here.


(In reply to comment #9)
> > the applet is still not unloading
> 
> The applet definitely _does_ "unload" when you close the window that contains
> it (at least it does in all my tests).  But Java does its own memory
> management, so "unloading" an applet has only an indirect effect on RAM usage.

I don't want to change the runtime parameters, as I do not expect the average
person has done so.  But I can establish that the applet is still running in
another way.  That is I use 't' to dump the thread list after closing the window
with the applet:


Dump thread list ...
Group main,ac=11,agc=2,pri=10
    AWT-AppKit,5,alive
    Thread-0,5,alive
    AWT-Shutdown,5,alive
    Thread-1,5,alive
    Thread-2,5,alive
    Thread-3,5,alive
    AWT-EventQueue-0,6,alive
Group Plugin Thread Group,ac=3,agc=0,pri=10
    Main Console Writer,6,alive
    AWT-EventQueue-1,6,alive
    TimerQueue,5,alive,dameon
Group
http://javadjvu.foxtrottechnologies.com/0/8/08/build/-threadGroup,ac=1,agc=0,pri=4
    Thread-8,4,alive
Done.


In comparison, I tried the same test in Safari:

Dump thread list ...
Group main,ac=6,agc=1,pri=10
    AWT-AppKit,5,alive,dameon
    AWT-Shutdown,5,alive
    AWT-EventQueue-0,6,alive
Group Plugin Thread Group,ac=3,agc=0,pri=10
    Main Console Writer,6,alive
    AWT-EventQueue-1,6,alive
    TimerQueue,5,alive,dameon
Done.

I see from this comparison two things.  First I was wrong in my speculation, a
top level thread group is being created for the applet.  But second I see not
only is the applet thread group still active, but there are several extra
threads running in the main group for Firefox beta that are not running in Safari.

Bill

> I don't want to change the runtime parameters, as I do not expect the
> average person has done so.

I wasn't asking you to tell others to do this.  I was asking you to do it
(temporarily), as a diagnostic tool.

> (Part of the "thread list" after you'd closed the window containing your
> applet:)
> Group
http://javadjvu.foxtrottechnologies.com/0/8/08/build/-threadGroup,ac=1,agc=0,pri=4
>    Thread-8,4,alive

Aha!  Now we're getting somewhere.  I'm able to reproduce this with your
applet, but not with another applet (picked at random):

http://java.sun.com/applets/jdk/1.4/demo/applets/ArcTest/example1.html

I will try to figure out why your applet's thread group isn't getting
destroyed.

> Thread-1,5,alive
> Thread-2,5,alive
> Thread-3,5,alive

These are (I think) non-Java threads created by the MRJ Plugin in order to be
able to do LiveConnect.


Does your applet explicitly start a thread?  (I notice that, while it's
running in Firefox, it has one more thread (for a total of three) than the
ArcTest applet has while it's running (in either Safari or Firefox).)

If so, the solution to the "undead thread group" problem may be to add code to
the Java Embedding Plugin to (somehow) guarantee that all threads an applet
has explicitly created get destroyed as the applet is destroyed.

(Also, interestingly, your applet has _four_ threads while it's running in
Safari, one of which is a "daemon" thread.)

The "undead thread group" problem, though, doesn't explain the continued high
CPU usage that you sometimes see after the window is closed.  I still think
the most likely explanation for that is a crash or a hang.  If you can find
relevant crash logs (from the
~/Library/Logs/CrashReporter/firefox-bin.crash.log file), please do attach
them here.


(In reply to comment #14)
> Does your applet explicitly start a thread?  (I notice that, while it's
> running in Firefox, it has one more thread (for a total of three) than the
> ArcTest applet has while it's running (in either Safari or Firefox).)

Yes.  It starts many threads.  All threads have an exit condition.  The thread
that remains running is:

  public void run()
  {
    while(DjVuObject.getFromReference(parentRef) != null)
    {
      try
      {
        Thread.sleep(5000L);
      }
      catch(final Throwable ignored) {}

      System.gc();
    }
  }

The method call:

DjVuObject.getFromReference(parentRef)

is equivalent to:

 parentRef.get()

where parentRef is a weak reference to the calling applet.  The fact that this
reference is never zero means the garbage collector is never cleaning up the
Applet reference.  Which is why if I open the applet again, more memory is used.
 If I do it too many times, out of memory exceptions start occuring.  That does
cause 100% cpu usage errors, but I don't think it is the same thing I saw
yesterday...

When I look at the thread dump I see that the garbage collector is stuck in an
Object.wait() call in a finalizer.  My code doesn't use  finalizers, but the
Java API does.  This could be normal, as maybe that is what the garbage
collector does when it is not running, but it looks odd.

Another strange thing I notice is in the Talkback report it reported my OS as
7.9 Darwin.  Could that mean the firefox is calling the wrong version of libraries?

Bill
(In reply to comment #14)
> the most likely explanation for that is a crash or a hang.  If you can find
> relevant crash logs (from the
> ~/Library/Logs/CrashReporter/firefox-bin.crash.log file), please do attach
> them here.

Sorry, I looked in the file, but I see no reports with yesterday's date.  I do
see  one from today when firefox died while running the applet.  I can attach
that if you wish.

Bill


> I do see one from today when firefox died while running the applet.  I can
> attach that if you wish.

I'd say don't bother.  I'd prefer you wait until another crash happens as (or
just after) you close a window with your applet in it.  Then the relevant log
should be easy to find :-)

> Another strange thing I notice is in the Talkback report it reported my OS
> as 7.9 Darwin.  Could that mean the firefox is calling the wrong version of
> libraries?

Actually, "Darwin 7.9.0" is correct ... if you're using OS X 10.3.9.  Run
"uname -a" at a Terminal prompt and see what you get.

(And I think you'll agree that bug 289612 ("repeatable crash when printing",
opened 2005-04-08), which is what the "Stack Signature" link takes you to, has
nothing to do with this bug (bug 307757).)

> Yes.  It starts many threads.  All threads have an exit condition.  The
> thread that remains running is: [...]

Thanks for this information.  It will (I hope) help me to track this problem
down.

> When I look at the thread dump I see that the garbage collector is stuck in
> an Object.wait() call in a finalizer

You mean in the "Finalizer" thread?

> This could be normal, as maybe that is what the garbage collector does when
> it is not running

Yes, I think so.  You see this even when an applet's thread group has been
successfully destroyed as the applet was destroyed.


(In reply to comment #17)
> (And I think you'll agree that bug 289612 ("repeatable crash when printing",
> opened 2005-04-08), which is what the "Stack Signature" link takes you to, has
> nothing to do with this bug (bug 307757).)

Yes.  Definitely printing has nothing to do with the stack trace.  How is the
Stack Signature linked to a bug number?  I definitely have never pressed the
print button on my Mac, and I see nothing in the stack trace to indicate
printing.  The last thing I see in the stack trace I recognize are awt calls.


But I suppose if there is a bug, it could be that printing is being called when
someone closes a window with an applet.  Stranger things have happen.  However,
I find it more likely the core signature is being mapped wrong.

Bill
Summary: Java on Firefox 1.5 beta eats up 100% cpu → Java on Firefox 1.5 beta sometimes uses 100% cpu after closing applet and sometimes crashes [@ CoreGraphics.203.30.0 + (00071cd8)]
Summary: Java on Firefox 1.5 beta sometimes uses 100% cpu after closing applet and sometimes crashes [@ CoreGraphics.203.30.0 + (00071cd8)] → Java on Firefox 1.5 beta sometimes uses 85% cpu even after closing applet and sometimes crashes [@ CoreGraphics.203.30.0 + (00071cd8)]
I figured out how to map the talkback report.  It looks like the mapping is just
a search of the summary line.
Assignee: yuanyi21 → pete.zha
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng
Steven, the reporter won't be back on this. Bill writes "Mac OSX 10.3 Pather has not offered any Java updates since I filed the bug in 2005.  I have not tried upgrading the Firefox version on that Mac. ... [and won't be]..."

leaving this to you and others to close this unconfirmed bug if appropriate (seems reasonable).
Several different issues are discussed in this bug, and (I think) at
least some of them are addressed in more recent versions of the Java
Embedding Plugin (which now, as then, is bundled with Mac distros of
Firefox, Camino and SeaMonkey).

I'm closing this bug WORKSFORME.  If any of the issues discussed here
come up again, they should be addressed in new bugs (one bug per
issue).
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.