93036 - Crash when auto-detect ALL of the page above

Status: VERIFIED WONTFIX

(Core :: Internationalization, defect)

Description

[Yuying Long]

Crash when auto-detect ALL of the page:
http://babel/testdata/Double_byte/euc-tw/euc-tw.html This is a with charset
EUC-TW page.

Crash on:
1. Mac: 07-26 US, 07-24 Japanese buuild / Mac9.0-Ja
2. Linux: 07-24 Japanese build / RedHat 6.2-Ja

Hang:
Linux: 07-26 US build / RedHat 6.2-Ja

No crash on hang:
Win32: 07-27 US, 07-27 Japanese build / WinME-Ja

See the Talkback ID:
Mac US build: 33575642
Mac Ja build: 33575091, 33575469
Linux Ja build: 33575573

Note: If I set auto-detect to Chinese, then won't see this crash on both Mac and
Linux (US and Ja build)

Comment 1

[Roy Yokoyama]

assigning to shanjian

Comment 2

[Shanjian Li]

My linux won't be up until I got my DSL and I don't have a mac. I took a look at 
the stack trace in talkback. The 3 mac instance looks like a memory/pointer 
issue, the linux instance does not seems related with charset detector. 

Naoki, 
can you take a look of this bug? What happened in 
"nsMBCSGroupProber::HandleData() [nsMBCSGroupProber.cpp, line 116] "? 
I hope it isn't very hard to figure out. 

Comment 3

[nhottanscp]

Okay, let me take a look if I can reproduce on my Macintosh.

Comment 4

[nhottanscp]

I need to pull a commercial tree. Today, I have other Mac related check in, so I
can try tomorrow.
Please move the bug to bugscape because this is commercial only.

Comment 5

[Shanjian Li]

If the problem is within universal detector, this bug can stay in bugzilla 
because we have a copy of universal detector in mozilla tree now. But be careful 
not post any sensitive file name here. We have different name in mozilla tree. 

Reassign to naoki. 

Comment 6

[nhottanscp]

change to netscape only, just in case

Comment 7

[nhottanscp]

It crashes on my Windows 2000 US, incident id 33646170.
Reassign to shanjian.

Comment 8

[nhottanscp]

On my Macintosh debug build, it crashes in EUCJ prober. The function takes a
buffer and a length. The buffer was allocated by the caller as 4096 bytes and
the passed length was 1011. So thoese seem to be fine. It crashes in the for
loop, and the stack is destroyed so no way I can know where exactly crashed.

Comment 9

[Asa Dotzler [:asa]]

If this bug is about mozilla code it cannot be marked Netscape Confidential.
unconfidentializing it.

Comment 10

[Frank Tang]

not sure it is related-
 93 hptr = highbyteBuf = (char*)PR_MALLOC(aLen);

you should check highbyteBuf null or not before using it.

Comment 11

[Shanjian Li]

I could not reproduce this one on either win2k and linux. Probably ftang is 
right. 

Comment 12

[Shanjian Li]

Attachment: patch based on ftang's assumption

Comment 13

[Shanjian Li]

I posted a patch to fix the problem found by ftang. If his assumption is 
correct, this should fix the bug. Naoki/frank, can you try it on mac if it is 
reproducible there? thx.

Comment 14

[Shanjian Li]

since I could not reproduce the problem on my nt/win2k/hp, I will assign this 
one to ftang. Noaki reproduce the problem on mac. 

Comment 15

[Jaime Rodriguez, Jr.]

--> msanz. ftang is on vacation.

Comment 16

[msanz]

reassigning to ftang. Shanjian, I have some questions:
is this a regression from 6.1?
What is so particular about the page? What other pages can users find with this
problem? Do you think it's common?
need more data before adding nsbranch+ or nsbranch-

Comment 17

[Shanjian Li]

> is this a regression from 6.1?
I was unable to reproduce the problem so far, I am not sure if this is a 
regression. My guess is not. 

>What is so particular about the page? What other pages can users find with this
problem? Do you think it's common?
The page is a testpage, which list all the code points available for euc-tw. It 
include many code points that are unused. I didn't expect a normal webpage would 
ever do that. The problem is we are not sure if that causes the crash. 

Comment 18

[msanz]

thanks a lot Shanjian, marking nsbranch- as per your comments. I will ask Frank
to review all nsbranch- when he is back next week

Comment 19

[Frank Tang]

mark it as m0.9.5 and reassign to shanjian.
shanjian the Mac crash problem is a seperate issue. mark it work for me if you 
still can reprodce it. 

Comment 20

[Jaime Rodriguez, Jr.]

Removing minus. Crashers are always good nominees.

Comment 21

[Shanjian Li]

I couldn't reproduce this. Resolve as worksforme. 

Comment 22

[Frank Tang]

QA, please try it again with clean install bits. 

Comment 23

[Yuying Long]

Re-open it cause I still can reproduce it on Linux and Mac, but not on Windows,
the result is same as before.

Change OS to other.

Talkback ID: 35651719 
Stack Signature .__ptr_glue adf4a43b  
Bug ID  
Trigger Time  2001-09-20 10:51:42  
Email Address  [e-mail]  
User Comments  bug 93036  
Build ID 2001091903  
Product ID Netscape6.20  
Platform ID MacOS  
Trigger Reason PowerPC unmapped memory exception  
Stack Trace  
.__ptr_glue 
nsMBCSGroupProber::HandleData() [nsMBCSGroupProber.cpp, line 116] 
nsAlisDetector::HandleData() [nsAlisDetector.cpp, line 448] 
nsAlisXPCOMDetector::DoIt() [nsAlisDetector.cpp, line 589] 
nsDetectionAdaptor::RawBuffer() [nsDetectionAdaptor.cpp, line 131] 
ParserWriteFunc() [nsParser.cpp, line 2625] 
nsPipe::ReadSegments() [nsPipe2.cpp, line 411] 
nsParser::OnDataAvailable() [nsParser.cpp, line 2675] 
nsDocumentOpenInfo::OnDataAvailable() [nsURILoader.cpp, line 241] 
nsHttpChannel::OnDataAvailable() [nsHttpChannel.cpp, line 2230] 
nsOnDataAvailableEvent::HandleEvent() [nsStreamListenerProxy.cpp, line 177] 
nsARequestObserverEvent::HandlePLEvent() [nsRequestObserverProxy.cpp, line 64] 
PL_HandleEvent() [plevent.c, line 590] 
PL_ProcessPendingEvents() [plevent.c, line 520] 
nsEventQueueImpl::ProcessPendingEvents() [nsEventQueue.cpp, line 374] 

Talkback ID: 35651525 
Stack Signature 0x12e040c7 6a77f442  
Bug ID  
Trigger Time  2001-09-20 10:47:29  
Email Address  [e-mail]  
User Comments  bug 93036  
Build ID 2001091705  
Product ID Netscape6.20  
Platform ID LinuxIntel  
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)  
Stack Trace  
0x12e040c7 
nsHttpChannel::OnDataAvailable() 
nsOnDataAvailableEvent::HandleEvent() 
nsARequestObserverEvent::HandlePLEvent() 
PL_HandleEvent() 
PL_ProcessEventsBeforeID() 
processQueue() 
nsVoidArray::EnumerateForwards() 
nsAppShell::ProcessBeforeID() 
handle_gdk_event() 
libgdk-1.2.so.0 + 0x17e4f (0x40334e4f) 
libglib-1.2.so.0 + 0x117f3 (0x403677f3) 
libglib-1.2.so.0 + 0x11dd9 (0x40367dd9) 
libglib-1.2.so.0 + 0x11f8c (0x40367f8c) 
libgtk-1.2.so.0 + 0x94803 (0x4027c803) 
nsAppShell::Run() 
nsAppShellService::Run() 
main1() 
main() 
libc.so.6 + 0x1c177 (0x404aa177) 

Comment 24

[Frank Tang]

shanjian, can you debug this on Linux ?

Comment 25

[Shanjian Li]

I can debug this on Linux. But this bug does not seem important to me. They test 
page is a very special page with so many unassign code points. You might also 
notice that the stack on linux does not seems to be a charset detector problem. 
This bug is not in my priority list. I would suggesting remove nsbranch+ keyword 
from this one. 

Comment 26

[lchiang]

Going through nsbranch+ bugs on behalf of PDT.  Mark pdt- per shanjian's most
recent comment and the earlier comment that this is not a regression.  If
disagree, pls remove PDT- for review again.

Also, cc: jpatel and shiva to see if this is a topcrash on the reports.  If so,
may need to revisit.

Comment 27

[Shanjian Li]

retarget.

Comment 28

[Yuying Long]

nsbeta1

Comment 29

[nhottanscp]

Please file this to bugscape.

Comment 30

[Yuying Long]

Open a bugscape bug:
http://bugscape.mcom.com/show_bug.cgi?id=11857

Mark this one as won't fix.

Comment 31

[Yuying Long]

Verified.