Closed Bug 176280 Opened 23 years ago Closed 20 years ago

browser hangs as java chokes on fphover.class

Categories

(Core Graveyard :: Java: OJI, defect)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 156493

People

(Reporter: bmo, Assigned: Louie.Zhao)

References

(
URL
)

Details

(Keywords: hang, Whiteboard: close)

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.
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)
URL: http://www.unicwash.org → http://www.unicwash.org/
Severity: major → critical
Keywords: hang
i'm using 1.3.1_02. grabbing new version, now.
*** This bug has been marked as a duplicate of 111944 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
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 → ---
Depends on: 111944
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
*** Bug 187118 has been marked as a duplicate of this bug. ***
Confirming, this affects all Win32 OSes
Status: UNCONFIRMED → NEW
Ever confirmed: true
WFM on Linux(RH8.0)/Windows 2000 mozilla1.2 JRE1.4.1_01
Whiteboard: close
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).
So, is it ok to mark this one as dup of bug 57372?
No because that bug is a crash of the browser not a hang.
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?
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.
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.
I think the reporter originally opened this bug because he thought mozilla shouldn't choke in these circumstances. Any comments reporter (Marc)?
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
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 :-)
and it is difficult to set timeout because it depend on a lot of other runtime environment
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
*** Bug 190029 has been marked as a duplicate of this bug. ***
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.
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.
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
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
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
matti?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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...
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?
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.
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.
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.
> 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
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.
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 ?
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
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?
->louie
Assignee: joshua.xia → Louie.Zhao
Status: REOPENED → NEW
*** Bug 146928 has been marked as a duplicate of this bug. ***
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
Closed: 23 years ago → 20 years ago
No longer depends on: 156493
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
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.