Closed Bug 105287 Opened 23 years ago Closed 21 years ago

Crash when loading the page above

Categories

(Core Graveyard :: Java: OJI, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: amyy, Assigned: nidheesh)

References

(
URL
)

Details

(Keywords: crash, intl, regression)

Attachments

(1 file)

the file - hs_err_pid4335.log
7.72 KB, text/plain
Details 
Build: 10-17 0.9.4 linux branch build on RH7.1-Ja

When loading page(during the loading process) http://news.chinatimes.com, 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.
Keywords: crash, intl
QA Contact: teruko → ylong
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.
Keywords: regression
->bstell
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.


    
    

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

    
    

    
  
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

    
  
Blocks: 107065

    
  
Keywords: nsbranch

    
    

    
  
The java plugin team is looking into this bug.
Status: NEW → ASSIGNED
Keywords: mozilla1.0

    
    

    
  
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.
Keywords: nsbeta1
Whiteboard: [PDT-]

    
    

    
  
*** 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.
URL: http://news.chinatimes.com → http://news.chinatimes.com; http://ja...

    
    

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


    
  
QA Contact: pmac → petersen

    
    

    
  
>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
Closed: 21 years ago
Resolution: --- → WORKSFORME

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: