browser hangs as java chokes on fphover.class

RESOLVED DUPLICATE of bug 156493

Status

Core Graveyard
Java: OJI
--
critical
RESOLVED DUPLICATE of bug 156493
16 years ago
5 years ago

People

(Reporter: Marc Bejarano, Assigned: Louie Zhao)

Tracking

({hang})

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: close, URL)

(Reporter)

Description

16 years ago
when i attempt to load the unicwash.org web site with moz 1.2b, the browser
hangs and has to be killed.  let me know if this can't be reproduced and i'll
investigate more on my end.

Comment 1

16 years ago
Reporter: What's your JRE version?
Upgrade to 1.4.x from http://www.javasoft.com if you're using 1.3.x
(There's a bug that causes JRE 1.3.x to hang with fphover)

Updated

16 years ago
Severity: major → critical
Keywords: hang
(Reporter)

Comment 2

16 years ago
i'm using 1.3.1_02.  grabbing new version, now.

Comment 3

16 years ago

*** This bug has been marked as a duplicate of 111944 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 4

16 years ago
please see the extensive discussion in bug 111944 as to why this is not a dupe.
 that bug tracks the bug in the JRE.  this bug tracks the fact that mozilla
can't cope with the JRE hanging and has to be killed just because the JRE gets
confused.  
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Updated

16 years ago
Depends on: 111944

Comment 5

16 years ago
Moving to appropriate component.
Assignee: asa → joshua.xia
Component: Browser-General → OJI
QA Contact: asa → petersen
Summary: browser hangs as java chokes → browser hangs as java chokes on fphover.class

Comment 6

16 years ago
*** Bug 187118 has been marked as a duplicate of this bug. ***

Comment 7

16 years ago
Confirming, this affects all Win32 OSes
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 8

16 years ago
WFM on Linux(RH8.0)/Windows 2000 mozilla1.2 JRE1.4.1_01
Whiteboard: close

Comment 9

16 years ago
The linux version of this bug is bug 57372. This bug is to do with the hanging
of the browser once JRE 1.3.x hangs in Windows (bug 111944 - marked as won't
fix, workaround is to upgrade to JRE 1.4.x).

Comment 10

16 years ago
So, is it ok to mark this one as dup of bug 57372?

Comment 11

16 years ago
No because that bug is a crash of the browser not a hang.

Comment 12

16 years ago
ian@arlen.demon.co.uk,
So, can we close this as WONTFIX? since it's fixed in new JRE version(1.4.1_01)
and there is no bug fix for JRE1.3.x?

Comment 13

16 years ago
That is why bug 111944 was closed as won't fix, this bug is to do with why a
plugin hanging causes the browser to hang. So perhaps it should be moved to the
plug-ins component.

Comment 14

16 years ago
The browser hangs because the OJI or JPI(plugin) is waiting for each other
because of some reason. Not because the pluging module I think.
I want to close it because I can't reproduce the hang and the crash in lates
version of JRE(1.4.x). If we don't close this one, it will be opened forever...
Because as I said, there is no bug fix for JRe1.3.x now.

Comment 15

16 years ago
I think the reporter originally opened this bug because he thought mozilla
shouldn't choke in these circumstances. Any comments reporter (Marc)?
(Reporter)

Comment 16

16 years ago
ian: you are correct about why i opened this bug :)

pete: please downgrade your JRE to repro the bug.  we can't have mozilla hang
just because somebody is using an older JRE, can we?  some sort of timeout needs
to be implemented if mozilla is waiting for some response it never gets.

marc

Comment 17

16 years ago
As I said, old version of JRE will not have bug fix. So, this bug will be opened
forever... But maybe it can catch some duplicates :-)

Comment 18

16 years ago
and it is difficult to set timeout because it depend on a lot of other runtime
environment
(Reporter)

Comment 19

16 years ago
pete said:
==
As I said, old version of JRE will not have bug fix. So, this bug will be opened
forever...
==
i understand that the old version of the JRE will not be fixed such that using
the fphover stuff is foolproof.  what i STILL don't understand is why mozilla
can't be made to handle in a more graceful manner the situation we end up in
when a user hits a page using fphover and they have a buggy JRE.  are you
suggesting there is no way for mozilla to detect this particular type of JRE hang?

marc

Comment 20

16 years ago
*** Bug 190029 has been marked as a duplicate of this bug. ***

Comment 21

16 years ago
comment 19,
Sometime, mozilla hangs but it not caused by mozilla itself. It is waiting the
reponse from JPI. And as comment 18, we don't have good solution to set timeout
because jvm and mozilla is running in different process and depending on the
system env.
(Reporter)

Comment 22

16 years ago
nobody ever said that making mozilla robust is trivial.  before i get too high
up on my horse, let me say that i'm not a programmer.  that said, pete and
joshua have yet to convince me that there is no solution to this problem.  we
can't expect a user to live with the fact that they lost 3 weeks of state in 30
open browser windows because there's a bug in the version of JRE that they are
using without a REALLY good explanation.  can somebody explain exactly what
mozilla is waiting for in this case?  and why we can't make mozilla at least pop
up an alert that says "it appears that your JRE is  hung.  click OK to put it
out of it's misery.  click cancel to sit for another 30 seconds and watch the
grass grow." ?

saying "it is difficult to set timeout because it depend on a lot of other
runtime environment" and "we don't have good solution to set timeout because jvm
and mozilla is running in different process and depending on the system env"
doesn't help somebody not intimately familiar with the internals understand the
insurmountable problem.

Comment 23

16 years ago
Telling everyone to just get the newest JRE is not a good solution.  I'm not
going to because I'm stuck using an old version of VisualCafe that doesn't work with
1.4, and 1.3.1 is what we build/test all our product with here at work (NT, AIX,
HPUX and Solaris).  We've had several customers tell us they don't plan to upgrade
to 1.4 for a couple years, even though because of advertised improvements in the
garbage collection we'd like them to.

If you watch the JRE history you'll see that there are frequent patches released
for this bug and that bug.  We even installed a patch on AIX lately that we got
from WebLogic/BEA rather than IBM.

Please try to find a solution in Mozilla.  Perhaps if you explain in a little
detail what the problem is, someone out there can suggest a solution you haven't
considered.  Maybe even me. :-)

-- Doug
reduping to bug 111944

You can't fix a bug in an old JRE. That a plugin can crash mozilla is a
different bug. search and you will find it.


*** This bug has been marked as a duplicate of 111944 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 25

16 years ago
matti: why are you marking bugs resolved when they haven't been?  if you want 
to make this dependent on another bug that tracks the meta-bug of plugins being 
able to crash the browser, that would make sense to me.  what doesn't make 
sense is marking resolved a bug that hasn't been resolved.  or am i missing 
something?

marc
(Reporter)

Comment 26

16 years ago
matti?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 27

16 years ago
I just discussed with Joshua.
Sometime, the browser hangs because JPI and JVM are waiting for each other. Not
because browser is waiting JPI or JVM. JPI and JVM are is the JRE release. So,
browser can do nothing in this case.
Joshua is investigating whether the hang is between JPI and JVM. If it is, we
will close this bug again...
(Reporter)

Comment 28

16 years ago
pete: thanks for the update!

i'm still confused, though.  if JPI is waiting for JVM and this somehow causes
the browser to need to be force-killed, thereby losing all the users' state, how
is this not a problem with the browser?  you still haven't convinced me that
there is absolutely nothing the browser can do to recover its sanity.

or am i completely off base, here?

Comment 29

16 years ago
hm, it's a long story. Here is the basic knowledge base:
The JPI(the plugin) is loaded by mozilla and running in same process of mozilla.
JVM is running in another process. JPI and JVM communicate with each other via
process call. So, if there should be timeout, JPI should use the timeout, not
mozilla.
For a simple example:
If you write a plugin which has a hole cause to hang(like some unlimited loop).
mozilla really could do nothing. Because it's not caused by mozilla, it caused
by the plugin itself.

So, if the problem is in JPI or JVM, what we can do is file bug against JRE and
wait them to fix it in furture release.
(Reporter)

Comment 30

16 years ago
why couldn't there be some button in the UI thread of mozilla that allows the
user to kill any JPI threads should they hang so that use of the browser can be
regained?  i wouldn't call that the most elegant solution, but it is a solution,
nonetheless, no?  anything that keeps me from having to lose all my mozilla
state when the JRE gets confused would be a big improvement in my book.

and i'm STILL not convinced that there is nothing the browser can do to maintain
its sanity.

Comment 31

16 years ago
The hang caused by fphover.class in JRE 1.3.x (which appeared in versions of 1.3
1.3.1_01a and above) was fixed in JRE 1.4.x so I presume it was discovered what
was causing the hang. Whether this was in the JRE or the JPI would come from Sun
I presume. If it was the JPI and as Pete says it runs in the same thread as
mozilla then, I guess, if that hangs, mozilla hangs. If it was the JRE then, I
guess that would be a problem to be fixed by Sun, which it has in 1.4.

Comment 32

16 years ago
> If it was the JPI and as Pete says it runs in the same thread as
> mozilla then, I guess, if that hangs, mozilla hangs.

You're saying that Mozilla has no way to deal with plug-ins that hang,
it's at their mercy?  Could someone point me at the source code
involved?  I'd like to download it and have a look.

-- Doug

Comment 33

16 years ago
Mozilla will not have the ability to kill thread which created by plugin.
Because there are no interface to do this. You know, not all plugin need to
create new threads. JPI is a special case.
AIK, the JPI will create two threads, one is to communicate with JVM. If that
thread hang, mozilla will hang. And mozilla don't know why itself hang.

If you want to read mozilla code related plugin and OJI, you may look at
folloring directory:
http://lxr.mozilla.org/seamonkey/source/modules/oji/
http://lxr.mozilla.org/seamonkey/source/modules/plugin/

An you should learn basic plugin knowledge here:
http://devedge.netscape.com/viewsource/2002/gecko-plugins/

I can't show the JPI and JVM code here for some reason that I think you can
understand.
(Reporter)

Comment 34

16 years ago
i'm assuming what you mean when you say:

> Mozilla will not have the ability to kill thread which created by plugin.

is "i'm not going to fix this glaring deficiency in the current plugin model
that mozilla uses in the way you suggest".  that's fair.  maybe somebody else
will :)  or maybe another solution will end up being more appropriate.  i STILL
don't buy that this bug should be marked a duplicate or should be resolved.  it
isn't either unless i'm missing something.  i know there are other bugs tracking
a rewrite of the plugin system to let them all use different processes.  maybe
we should make this dependent on bug 156493 ?

Comment 35

16 years ago
Yes, this bug is depend on 156493.

>is "i'm not going to fix this glaring deficiency in the current plugin model
>that mozilla uses in the way you suggest"
No, I'm sorry you feel that I don't want to fix this. I just mean in technique
way, we don't have good solution right now to fix it. See bug 156493, they are
discussing but still have no result. And I think it may take a long time. So, I
think fix those problem in plugin is much easier than fix it in mozilla in
current situation.
Depends on: 156493
(Reporter)

Comment 36

16 years ago
agreed that the easy fix for this particular hang is / was in the plugin.  this
bug ticket was specifically to track that mozilla couldn't handle the hang
gracefully, though.  so can we agree to keep this bug open until that situation
changes?

Comment 37

15 years ago
->louie
Assignee: joshua.xia → Louie.Zhao
Status: REOPENED → NEW

Comment 38

15 years ago
*** Bug 146928 has been marked as a duplicate of this bug. ***

Comment 39

13 years ago
The assertion has been made repeatedly that this bug is about Mozilla gracefully
handling a plug-in that hangs. To the extent that any solution to that general
problem can be imagined at this time, this bug duplicates bug 156493.


*** This bug has been marked as a duplicate of 156493 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago13 years ago
No longer depends on: 156493
Resolution: --- → DUPLICATE

Updated

8 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard

Comment 40

5 years ago
Just in case this gets separated again into a separate bug for the Mozilla fragility issue: I just experienced this problem again, years later, when visiting www.chakraplein.nl/allin_taylor.htm. I am running Java 1.7.0 (the latest). Firefox 19.0.2, Windows XP Home SP3, computer otherwise running well. I will also enter this info at bug 156493. The problem should be fixed (either in Java or Mozilla) because it looks exactly like malware (a phishing attempt to get the user to click OK to gain access to install malware).
You need to log in before you can comment on or make changes to this bug.