Crash when loading the page above



Core Graveyard
Java: OJI
17 years ago
8 years ago


(Reporter: Yuying Long, Assigned: Nidheesh Dubey)


({crash, intl, regression})

crash, intl, regression

Firefox Tracking Flags

(Not tracked)




(1 attachment)



17 years ago
Build: 10-17 0.9.4 linux branch build on RH7.1-Ja

When loading page(during the loading process), the
application got crashed, no talkback window pops-up.

I got the error message in terminal window:
INTERNAL ERROR on Browser End: Pipe closed during read?
State may be corrupt system error??

./mozilla-bin just dumped a core file

This is another page with JavaScript, don't know if it is the same problem as
bug 105275.  Please change the component if not an i18n problem.


17 years ago
Keywords: crash, intl
QA Contact: teruko → ylong

Comment 1

17 years ago
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.


17 years ago
Keywords: regression

Comment 2

17 years ago
Assignee: yokoyama → bstell

Comment 3

17 years ago
(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

Comment 4

17 years ago
Created attachment 53974 [details]
the file - hs_err_pid4335.log

Comment 5

17 years ago
what are the chances this could be resolved tonight?

Comment 6

17 years ago
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.

Comment 7

17 years ago
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

Comment 8

17 years ago
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
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/ to
plugins/java2/lib/ 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

Comment 9

17 years ago
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

Comment 10

17 years ago
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.

Comment 11

17 years ago
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.

Comment 12

17 years ago
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)
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

Comment 13

17 years ago
see the log, it seems a Linux only java crash

Comment 14

17 years ago
I looks like the root of problem is in
sun.awt.motif.X11Graphics.disposeImpl(Native Method)
from the log.

Comment 15

17 years ago
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/
with the content of  plugins/java2/lib/ then it won't crash. So
definitely the bug is inside Java and probably the font handling code of AWT.

Comment 16

17 years ago
Is this related to ?
This does not happen with 10-17-0.9.4 linux build in Redhat 6.2 JA.

Comment 20

17 years ago
we should look at this one.
Keywords: nsbranch
Whiteboard: [PDT]

Comment 21

17 years ago
ylong- can you test N6.1 (with java install from the N6.1 installer)

Comment 22

17 years ago
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 ?

Comment 23

17 years ago
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".

Comment 24

17 years ago
> 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.

Comment 25

17 years ago
However, it crashed on N6.2 by doing the same setting as above - the crash
result is same as in original report.

Comment 26

17 years ago
With environment variable LD_ASSUME_KERNEL set to 2.2.5,
NS 6.1 works on
Sun's Java i18n demo pages.

But the latest linux 0.9.4 build crashes in the same environment.

Comment 27

17 years ago
so this is a regression from 6.1

Comment 28

17 years ago
Frank: do you think this is related to the font problems described in bug 100880?

Comment 29

17 years ago
100880 is window only bug.

Comment 30

17 years ago
add ron to the cc list

Comment 31

17 years ago
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.

Comment 32

17 years 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:(

Comment 33

17 years ago
ok, that mean the only think could fix the problem is to fix JVM

Comment 34

17 years ago
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-]

Comment 35

17 years ago
moving to oji
Assignee: idk → nidheesh
Component: Java-Implemented Plugins → OJI


17 years ago
Blocks: 107065


17 years ago
Keywords: nsbranch

Comment 36

17 years ago
The java plugin team is looking into this bug.
Keywords: mozilla1.0

Comment 37

17 years ago
I can not see the crash using JRE 1.4 beta3 which is available from

Comment 38

17 years ago
Ftang - This is a crash your team might want to take an early look at for MachV.
Keywords: nsbeta1
Whiteboard: [PDT-]

Comment 39

17 years ago
*** Bug 115317 has been marked as a duplicate of this bug. ***

Comment 40

17 years ago
Set correct QA contact
Assignee: nidheesh → joe.chou
QA Contact: avm → pmac

Comment 41

17 years ago
Oops, sorry.
Return assignment back.
Assignee: joe.chou → nidheesh

Comment 42

17 years ago has same crash, add it into URL field.

Comment 43

17 years ago
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?


Comment 44

17 years ago
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.

Comment 45

16 years ago
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.

Comment 46

16 years ago
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

Page has been updated so that I could see the crash on that

Comment 47

16 years ago
> 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

Comment 48

16 years ago
EXIT(3) Linux Programmer's Manual             EXIT(3)
 exit - cause normal program termination
 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:(


16 years ago
QA Contact: pmac → petersen

Comment 49

16 years ago
>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

Comment 50

16 years ago
does this happen on 1.4_01 ?

Comment 51

16 years ago
Both and 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.

Comment 52

16 years ago
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.

Comment 53

16 years ago
By the definitions on <> and
<>, 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

Comment 54

15 years ago
seems that this is not a problem any longer
per i18 triage: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 55

15 years ago
-- 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.
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME


8 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.