33029 - crashed when loading the www.focus.de

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[Charles Wang]

OS/Win98 and Red Hat Linux 6.0

Build ID 2000-03-23-05/06

Steps to reproduce:

1. type URL: www.mozilla.org/quality/smoketests
2. Click International link in the page
3. Click www.focus.de site

result:

crashed when loading the www.focus.de

This didnt happen on MAC

Comment 1

[Charles Wang]

This behavior happened olny once on Linux and Win98. And not reproducable after 
that

Comment 2

[Bernd Mielke]

My debug build 2000032309 under Win98 does not show anything special, nice
stories, no asserts.

Comment 3

[Teruko Kobayashi]

I cannot reproduce this in 2000032305 Linux build.  

Comment 4

[Frank Tang]

Do you have a talk back stack trace ? somehow my private build take forever to
load that site. It didn't crash, but is is weired.

Comment 5

[Teruko Kobayashi]

Talkback incident # 7327173
Trigger Type:  Program Crash 

 Trigger Reason:  Access violation 

 Thread ID:   

 Call Stack:    (Signature = nsAutoString::nsAutoString 2f345c36) 
 nsAutoString::nsAutoString 
[d:\builds\seamonkey\mozilla\xpcom\ds\nsString2.cpp, line 2264]
 HTMLContentSink::OnStreamComplete
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp, 
line 4218]
 Registers:  Not Available 
 Command Line:  "C:\Program Files\Netscape 6\netscp6.exe" -installer 

Comment 6

[Teruko Kobayashi]

Another talkback report for Linux build.
Talkback incident #7327155
 Trigger Type:  Program Crash 

 Trigger Reason:  SIGSEGV: Segmentation Fault: (signal 11) 

 Call Stack:    (Signature = nsAutoString::nsAutoString() c94bd8fb) 
     
   nsAutoString::nsAutoString() 
   HTMLContentSink::OnStreamComplete() 
   nsStreamLoader::OnStopRequest() 
   InterceptStreamListener::OnStopRequest() 
   nsHTTPChannel::ResponseCompleted() 
   nsHTTPServerListener::OnStopRequest() 
   nsOnStopRequestEvent::HandleEvent() 
   nsStreamListenerEvent::HandlePLEvent() 
   PL_HandleEvent() 
   PL_ProcessPendingEvents() 
   nsEventQueueImpl::ProcessPendingEvents() 
   event_processor_callback() 
   our_gdk_io_invoke() 
   libglib-1.2.so.0 + 0xdd6a (0x40798d6a) 
   libglib-1.2.so.0 + 0xf2c6 (0x4079a2c6) 
   libglib-1.2.so.0 + 0xf801 (0x4079a801) 
   libglib-1.2.so.0 + 0xf979 (0x4079a979) 
   libgtk-1.2.so.0 + 0x85f3a (0x406c9f3a) 
   nsAppShell::Run() 
   nsAppShellService::Run() 
   main1() 
   main() 
   libc.so.6 + 0x17cb3 (0x4030ecb3) 
                                                

Comment 7

[bobj]

Works for me.  Win95 running 2000-03-23-06-M15-nb1b build.
Is this only happening on the trunk?

Comment 8

[bobj]

jbetak, Could this be related to your changes in HTMLContentSink?

Comment 9

[[e-mail] (away - not reading bugmail)]

bobj, this sure looks like it. Both the focus.de and the microsoft.com/support 
are not reproducable anymore (I tried several different pre-Beta1 builds and 
the trunk with and without the HTMLContentSink fix).

Tentatively merking as duplicate of 32785 and 32604.

Comment 10

[[e-mail] (away - not reading bugmail)]

this looks quite bad actually - found a way to reproduce in both the Beta 1 and 
the trunk:

make sure your default charset = ISO 8859-1 and load either http://www.focus.de 
or http://home.netscape.com, now set the default charset to say EUC-JP.

Mozilla crashes for the same reason it did in both bug 32604 and 32785. We are 
trying to construct a string with size 0 and the underlying string class can't 
handle it. The problem with this bug is that we currently don't catch it in 
Beta1.

I'm taking it out of ftang's batch since I tracked the problem down to my code 
changes in nsHTMLContentSink.cpp.

Comment 11

[Charles Wang]

Observed on Win32 2000-03-27-19-M15-nb1b and MAC 2000-03-27-23-M15-nb1b 

It crashed first time when I loaded this page both on MAC OS 9 and Win98. (It 
didn't happen on Linux today). loading second time,it didn't crash, but both 
systems display blank pages. then I tried more times. They loaded but took long 
time.

Comment 12

[bobj]

There appears to be 2 bugs:  (1) failure to look up correct charset 
converter for JS in some cases, and (2) nsAutoString crashes when asked to 
contruct a 0 length string.

We have a workaround for Beta1 that we can document in release notes for
users to avoid crashing in most cases, but if there is a Beta1 respin, we
want to fix the crash.

I'll add a comment later on the workaround.

Comment 13

[bobj]

For the Beta1 Release notes:

There is a crashing bug when using the Character Coding menu on pages with
external JavaScript files.  To avoid the most common cases, users should
enable the appropriate Character Coding Auto-Detect:

  Japanese users should enable:
         View|Character Coding|Auto-Detect (Japanese)
         [Note: The localized Japanese version will default to this value.]
  Korean users should enable:
         View|Character Coding|Auto-Detect (Korean)
  Traditional Chinese users should enable:
         View|Character Coding|Auto-Detect (Traditional Chinese)
  Simplified Chinese users should enable:
         View|Character Coding|Auto-Detect (Simplified Chinese)

This workaround eliminates the need to use the View|Charset Coding menu in
most cases which causes this crash.

Comment 14

[[e-mail] (away - not reading bugmail)]

per discussion with Cata, we would have a fix for a tentative Beta 1 respin. The 
patch takes the all-lowercase charset ID passed down from our UI´s JavaScript 
logic and converts it to the canonical form before going any further. If 
applied, this could help to clean up some other issues as well.

Comment 15

[leger]

Putting on PDT+ radar for respin if we do.

Comment 16

[[e-mail] (away - not reading bugmail)]

since there was not JS respin for Beta1, I just checked in some more error 
handling code into the M15 trunk to prevent us from crashing as discussed 
with bobj and ftang...

Verified on Win32 (NT) and Corel Linux and closing down for both Beta1 (didn't 
make it into the final distribution there) and M15

Comment 17

[Teruko Kobayashi]

I verified this in 2000041306 Win32, 2000041307 Mac, and 2000041310 Linux build.