I think it's a regression - I didn't see the crash on 10-02 branch build but crashed on 10-15 branch build though. It's might cause by plug-ins, cause on 10-02 build, there is a download plug-in dialog pops-up but 10-17 build doesn't.
Assignee: yokoyama → bstell
(ftang using ylong's accout): I see the following on the console when it crash: Local Time = Wed Oct 17 15:40:50 2001 Elapsed Time = 7 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.3.1-b24 mixed mode) # # An error report file has been saved as hs_err_pid4335.log. # Please refer to the file for further information. # INTERNAL ERROR on Browser End: Write failed. sendrequest System error?:: ¥Ñ¥¤¥×¤¬ÀÚÃÇ¤µ¤ì¤Þ¤·¤¿ Oh no! ./mozilla-bin just dumped a core file. Do you want to debug this ? You need a lot of memory for this, so watch out ? [y/n] n [root@h-208-12-37-219 1017b]# I will also attach the file hs_err_pid4335.log
what are the chances this could be resolved tonight?
Could the page have changed between when you tested on the 10-2 build vs. today's build? What happens if you go back to the 10-2 build now? (I couldn't tell from the comments if this was done or if you were recalling your 10-2 results from the past.) Thanks.
from Lisa ... "Jay - can you look at the talkback reports to see if these are top crashes? Ylong - ... "has the site changed betweeen 10-2 (when the reporter says the bug was working last) and now? It'd be interesting to go back to the 10-2 build to try."
ok, here is what I find out: 1. the commet ylong make about previous build don't have the problem is not accurate. She didn't install java on those build . I think the crash is inside java 2. If we setenv LANG ja_JP (or fr, or ko, or zh) and run it, it will crash. 3. If we setenv LANG C it will not crash 4. If I copy plugins/java2/lib/font.properties to plugins/java2/lib/font.properties.ja then it will not crash when we set the LANG to ja_JP So... we believe this is a Java crashing bug. Give to java group we try it in 10/02 build with java installed. It don't crash but HANG.
Assignee: bstell → idk
Component: Internationalization → Java-Implemented Plugins
QA Contact: ylong → avm
lchiang: I work with ylong right now. I think her previous commet about 10/02 build is wrong. She was testing withoug Java installed. And the bug only show up after install java. we install java on her 10/02 build and it then hang
Is this only on Linux? I tried this on the Win32 builds and all were ok. --> 2001-10-17-05-094 branch build (installed using Custom install with all components checked so Java is installed). I loaded the China Times page. I do get a dlg asking to download fonts (since I don't have the right fonts) and I canceled that dialog. The page finishes loading - the characters just don't display in the Chinese font.
Does anyone have a stacktrace or a Talkback incident for this crash? Either or both of those pieces of information would help determine if this is a topcrasher.
Here is the relation ship between LANG and crash or not (assume there no LC_ALL or other LC_ set to other value, or you set to the save value as LANG) LANG C won't crash en won't crash ja won't crash (somehow start up as English UI) ja_JP will crash (start up as Japanese UI) zh won't crash zh_TW won't crash zh_CN won't crash fr won't crash
see the log, it seems a Linux only java crash
I looks like the root of problem is in sun.awt.motif.X11Graphics.disposeImpl(Native Method) from the log.
as I say, currently this problem only happen when we run on Linux and under LANG (or LC_ALL) set to ja_JP and if I replace the with the content of plugins/java2/lib/font.properties.ja with the content of plugins/java2/lib/font.properties then it won't crash. So definitely the bug is inside Java and probably the font handling code of AWT.
Is this related to http://bugzilla.mozilla.org/show_bug.cgi?id=84093 ? This does not happen with 10-17-0.9.4 linux build in Redhat 6.2 JA.
with LANG set to ja_JP, it also crash (The same way ) in http://java.sun.com/applets/jdk/1.1/demo/i18n/Collate/index.html (you need to wait about 10 second to see the crash while it finish the loading of java class file) http://java.sun.com/applets/jdk/1.1/demo/i18n/DateTimeFormat/index.html http://java.sun.com/applets/jdk/1.1/demo/i18n/MessageFormat/index.html http://java.sun.com/applets/jdk/1.1/demo/i18n/NumberFormat/index.html http://java.sun.com/applets/jdk/1.1/demo/i18n/TextBound/index.html
http://java.sun.com/applets/jdk/1.1/demo/ArcTest/index.html DOES NOT crash http://java.sun.com/applets/jdk/1.1/demo/NervousText/index.html DOES NOT crash
also crash in real page http://www.people.or.jp/~env/applets/blurdark.html
we should look at this one.
ylong- can you test N6.1 (with java install from the N6.1 installer)
It seems JavaVM died for some reason. av: (or maybe someone else who handle the Java and Netscape intergration) Is there a way we can catch the execption and don't die with JavaVM ?
Checked it on N6.1 (both my machine and Xianglan's machine), it hangs, and then I can not find "mozilla" in cpu when I tried "top".
> re you testing NS 6.1 on RH 7.1? If so, the hang may be due to a known old > problem with the JRE. Set enviornment variable LD_ASSUME_KERNEL=2.2.5 and does it > still hang? NS 6.2 will have JRE 1.3.1 which should not show this problem. > -peterl -- after I did the change, the page loads very slow but can complete fine.
However, it crashed on N6.2 by doing the same setting as above - the crash result is same as in original report.
With environment variable LD_ASSUME_KERNEL set to 2.2.5, NS 6.1 works on http://news.chinatimes.com Sun's Java i18n demo pages. But the latest linux 0.9.4 build crashes in the same environment.
so this is a regression from 6.1
Frank: do you think this is related to the font problems described in bug 100880?
100880 is window only bug.
add ron to the cc list
ftang wrote: > av:I am not sure you are the right person to deal with this or not. It seem > the Linux Java die in this bug. Is there a way to make Mozilla don't die with > JavaVM ? This issue has been floating aroung for a while. On Windows we have a mechanism to attempt to catch an exeption in plugin. There are some difficulties implementing the same thing on Unix and it will never guarantee the success either. Cc'ing serge for more input as he investigated this some time ago.
Well, unfortunately not much we can do if plugin's code does corrupt some process's resources. Plugin is just a dll, which code execs inside mozilla's process, and can you imaging what happens if plugin corrupts the stack pointer? In best case scenario we can catch the signals and longjmp from signal handler trying to exit properly:(
ok, that mean the only think could fix the problem is to fix JVM
PDT-, because this is in the JVM, and can't be worked around in our code, without a news feature for unix.
Whiteboard: [PDT] → [PDT-]
moving to oji
Assignee: idk → nidheesh
Component: Java-Implemented Plugins → OJI
The java plugin team is looking into this bug.
Status: NEW → ASSIGNED
I can not see the crash using JRE 1.4 beta3 which is available from http://java.sun.com/j2se.
Ftang - This is a crash your team might want to take an early look at for MachV.
*** Bug 115317 has been marked as a duplicate of this bug. ***
Set correct QA contact
Assignee: nidheesh → joe.chou
Status: ASSIGNED → NEW
QA Contact: avm → pmac
Oops, sorry. Return assignment back.
Assignee: joe.chou → nidheesh
http://java.sun.com has same crash, add it into URL field.
Yuying Long, Which JRE are you using? As Xiaobin notes the 1.4 available from Sun does not display any problem. Could you try that? nidheesh
I was using 1.3.1. I might try it with 1.4 later, however I was told by a person in Sun China that they saw the crash with verson 1.4 too. And since our N6.2.1(also mozilla 0.9.8) was boundled with v1.3.1, I think it has to be fixed.
WFM on Linux RH 7.1 for trunk build (20020311) with JRE 1.3.1_01 and on Linux RH 6.2 for trunk build (20020228) with JRE 1.3.1-b24. In both cases I used the following variants of locale: C, ru.koi8-r, ja_JP anf fr. Browser doesn't crash in all cases.
Still see the same crash on 03-11 trunk build (the java looks like vJRE 1.3.1-b24)/RH7.2 with ja_JP.eucJP locale on http://sun.java.com. Page news.chinatimes.com has been updated so that I could see the crash on that site.
> Well, unfortunately not much we can do if plugin's code does corrupt some > process's resources. As for java plugin, it exit() every time something happens. Even if it can simply bail out and return error code. I found 69 |exit()|s in java plugin code (browser side). :-))) Even JVM crashes shouldn't crash mozilla, because jvm running in a separate process communicating with the browser plugin via pipe. But this is task for java plugin folks
EXIT(3) Linux Programmer's Manual EXIT(3) NAME exit - cause normal program termination DESCRIPTION The exit() function causes normal program termination and the value of status is returned to the parent. All functions registered with atexit() and on_exit() are called in the reverse order of their registration, and all open streams are flushed and closed. --- that means if java plugin, which is running in borrower's process space, calls exit() whole process will be terminated:(
>As for java plugin, it exit() every time something happens. >Even if it can simply bail out and return error code. >I found 69 |exit()|s in java plugin code (browser side). :-))) Could you list where are these 69 exit() code ? if this is in the browser side, could you point out the file and line number in the mozilla source, thanks
does this happen on 1.4_01 ?
Both http://news.chinatimes.com and http://java.sun.com changed, there is no applets any more, so there is no crashes now. And I can not reproduce the crashes with some other pages that mentioned in this bug with latest build / jre1.4.1_01 on RH7.2-JA.
This bug can't reproduce on the following environment: Redhat 7.2, mozilla 1.0.1, jre1.4.0_03 and jre1.4.1_01 Redhat 8.0, mozilla 1.1, jre1.4.0_03 and jre1.4.1_01 There are no crash and no error.
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
seems that this is not a problem any longer per i18 triage: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
-- Verified in the latest trunk build on winXP with JRE1.4.1_02. I can visit the above urls without crashing. Marking WORKSFORME. If you still see the crash please change the resolution.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.