85487 - M091 crash at line breaker [@ nsJISx4501LineBreaker::Next]

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P1)

Description

[greer]

M091 seems be having trouble computing the proper line breaks. Here are the 
user comments and stack from the talkback reports:

     (31595420) URL: www.hushmail.com AND limewire.com
     (31595420) Comments: Checking my hushmail account (running javascipt)while
tryring to to download the limewire client.btw the way - the mozilla 0.9.1 one
is excellent. Well done to all involved.regardsjames

     (31574959) URL: http://freelance.bocuma.com
     (31574959) Comments: trying to view source

     (31533521) URL: www.astrofoto.org/~roland/
     (31533521) Comments: going back a page

     (31502739) URL: www.astaro.com/products/download.html
     (31502739) Comments: i clicked on the iso image of astaro security linux
and mozilla tried to display the iso.gz file (and crashed)

     (31497297) URL: https://homelink.fleet.com/HomeLink
     (31497297) Comments: viewing frame source. also
     (31497297) Comments:  http://homelink.fleet.com which takes you to the
above secure link once you press the Login graphic.


Stack Trace: 

         nsJISx4501LineBreaker::Next
[d:\builds\seamonkey\mozilla\intl\lwbrk\src\nsJISx4501LineBreaker.cpp  line 462]
         nsTextFrame::ComputeWordFragmentWidth
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp  line 5337]
         nsTextFrame::ComputeTotalWordWidth
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp  line 5262]
         nsTextFrame::MeasureText
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp  line 4777]
         nsTextFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp  line 5016]
         nsLineLayout::ReflowFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp  line 956]
         nsBlockFrame::ReflowInlineFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3460]
         nsBlockFrame::DoReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3344]
         nsBlockFrame::DoReflowInlineFramesAuto
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3269]
         nsBlockFrame::ReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3215]
         nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2337]
         nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2027]
         nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 795]
         nsBlockReflowContext::DoReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp  line
573]
         nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp  line
343]
         nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2960]
         nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2223]
         nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2027]
         nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 795]
         nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line
745]
         CanvasFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp  line 579]
         nsBoxToBlockAdaptor::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line
869]
         nsBoxToBlockAdaptor::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line
525]
         nsBox::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line
985]
         nsScrollBoxFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp  line 379]
         nsBox::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line
985]
         nsContainerBox::LayoutChildAt
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp  line 595]
         nsGfxScrollFrameInner::LayoutBox
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line
1039]
         nsGfxScrollFrameInner::Layout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line
1149]
         nsGfxScrollFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line
1047]
         nsBox::Layout  
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line
985]
         nsBoxFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 781]
         nsGfxScrollFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line
738]
         nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line
745]
         ViewportFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp  line 538]
         nsHTMLReflowCommand::Dispatch
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp  line
145]
         PresShell::ProcessReflowCommand
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 5712]
         PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 5767]
         ReflowEvent::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 5625]
         PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c  
line 591]
         PL_ProcessPendingEvents        
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c 
line 524]
         _md_EventReceiverProc  
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c 
line 1072]
         nsAppShellService::Run
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp  line 418]
         main1  [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  
line 1159]
         main   [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  
line 1453]
         WinMain        
[d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp  line
1471]
         WinMainCRTStartup()
         KERNEL32.DLL + 0x7903 (0x77e87903)

Comment 1

[greer]

Adding crash, topcrash keywords. Not yet able to repro the crash on WinNT. 
Adding qawanted keyword.

Comment 2

[nhottanscp]

Reassign to ftang, cc to shanjian.

Comment 3

[nhottanscp]

I tried on Windows 2000 but cannot reproduce the crash, so far.
I used a branch build 2001-06-11-06-0.9.1.

Comment 4

[nhottanscp]

Seems like it is related to the fix of bug 19265 [TEXT] Word-wrap improperly
breaks before space following last word [INLINE]
It modified nsTextFrame.cpp (rev=1.307) which calls nsJISx4501LineBreaker.cpp.
The check in was on 6/4/2001.

Comment 5

[Frank Tang]

we should take a look at shanjians' recent work (not check in yet) in bug 72415. 
It seems the fix in there are close to the problem code. 

Comment 6

[Frank Tang]

reassign to yokoyama to work on . P1 moz0.9.2. cc [e-mail]

Comment 7

[Roy Yokoyama]

shanjian has a patch for
http://bugzilla.mozilla.org/show_bug.cgi?id=72415;
but his patch wouldn't fix this bug since the first call to
ComputeWordFragmentWidth() will crash.

Comment 8

[Roy Yokoyama]

I tried on Windows 2000-Ja but cannot reproduce the crash, so far.
I used a trunk debug build 2001-06-12.

Comment 9

[Frank Tang]

reassign to ftang since we cannot reproduce this on window.

Comment 10

[greer]

On my NT box I just crashed two times using these steps:
1. Go to: www.astaro.com/products/download.html
2. Clicked on: http://download.astaro.com/iso/asl-1.811.iso.gz
(I got a screen of junk)
3. Scroll up and down for a while (I went as far as the Public License.)
4. (I also clicked in the window, though I doubt that had any effect.)
5. Crash

On crash happened almost immediately, the other took a minute while the page 
continues to load. See Talkback incidents 31720318 and 31720778.

Comment 11

[Frank Tang]

I still cannot reprodue this. Neither on my NT  nor on my linux box.

Comment 12

[Frank Tang]

jbetak- can you try to predroduce this on window or Linux?

Comment 13

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

accepting, I'll try to reproduce it today...

Comment 14

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

confirming greer's repro steps:

1) install 6.10 B1
2) go to http://download.astaro.com/iso/asl-1.811.iso.gz

Wait for the file contents to be rendered in the browser window, this migth 
take a little while. The Preview 1 build crashes pretty reliably on my 
machine... I'll doublecheck on my home system.

Comment 15

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

Confirming repro steps from a second W2K machine with a trunk build.

Comment 16

[Frank Tang]

clear status witeboard. 
jbetak- please clearify what configuration can crash. It seems you can reprodue 
this on win2K. What else?
don't try to fix it by yourself. Once you can reproduce this problem. Grab me to 
debug with you.

Comment 17

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

ftang:

the crasher seems to be Win only. I just looked into my debug build and this is 
the stack trace I saw:

memcpy(unsigned char * 0x02b2aff0, unsigned char * 0x048d7b28, unsigned long 
7007) line 171
nsCRT::memcpy(void * 0x02b2aff0, const void * 0x048d7b28, unsigned int 7007) 
line 103 + 17 bytes
nsTextFrame::ComputeTotalWordWidth(nsIPresContext * 0x03b91350, nsILineBreaker 
* 0x045b3590, nsLineLayout & {...}, const nsHTMLReflowState & {...}, nsIFrame * 
0x02b30a04, int 385125, unsigned short * 0x048d7b28, unsigned int 1975, 
unsigned int 2456) line 5306 + 23 bytes
nsTextFrame::MeasureText(nsIPresContext * 0x03b91350, const nsHTMLReflowState & 
{...}, nsTextTransformer & {...}, nsILineBreaker * 0x045b3590, 
nsTextFrame::TextStyle & {...}, nsTextFrame::TextReflowData & {...}) line 4810 
+ 65 bytes
nsTextFrame::Reflow(nsTextFrame * const 0x02bfc9d4, nsIPresContext * 
0x03b91350, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, 
unsigned int & 1232064) line 5048 + 43 bytes
nsLineLayout::ReflowFrame(nsIFrame * 0x02bfc9d4, nsIFrame * * 0x0012d6f4, 
unsigned int & 1232064, nsHTMLReflowMetrics * 0x00000000, int & 0) line 955 + 
43 bytes

Might be related to bidi...

Comment 18

[Frank Tang]

I look at the new code and the new crash. I think we have the following problems 
at least. Not sure it will fix the origional crash or not.

5302           if (newWordBuf != aWordBuf) {
5303             newWordBuf = (PRUnichar*)nsMemory::Realloc(newWordBuf, 
sizeof(PRUnichar)*newWordBufSize);
5304           } else {
5305             newWordBuf = 
(PRUnichar*)nsMemory::Alloc(sizeof(PRUnichar)*newWordBufSize);
5306             nsCRT::memcpy((void*)newWordBuf, aWordBuf, 
sizeof(PRUnichar)*newWordBufSize-moreSize);
5307           }
1. We should check the result of Reallocate and Allocate after line 5303 and 
5305
I don't know what can we do here since this function do not let us return error 
code.

Look at nsTextFrame::ComputeWordFragmentWidth, it seems return *stop = PR_TRUE 
with return value 0 when it hit error case. maybe we should do the same thing 
while we cannot allocate memory.


I think we should at least add
NS_ASSERTION(newWordBuf, "cannot allocate memory");
after that two line.


2. the 3rd argument of memcpy in line 5306 should be 
sizeof(PRUnichar)*(newWordBufSize-moreSize)
not
sizeof(PRUnichar)*newWordBufSize-moreSize
I think this is the cause of jbetak's last crash.

Comment 19

[Frank Tang]

5298         if (moreWidth < 0) {
5299           PRUint32 moreSize = -moreWidth;
5300           //Oh, wordBuf is too small, we have to grow it
5301           newWordBufSize += moreSize;
5302           if (newWordBuf != aWordBuf) {
5303             newWordBuf = (PRUnichar*)nsMemory::Realloc(newWordBuf, 
sizeof(PRUnichar)*newWordBufSize);
+                  NS_ASSERTION(newWordBuf, "no enough memory");
5304           } else {
5305             newWordBuf = 
(PRUnichar*)nsMemory::Alloc(sizeof(PRUnichar)*newWordBufSize);
+                  NS_ASSERTION(newWordBuf, "no enough memory");
+                  if(newWordBuf)
!                     nsCRT::memcpy((void*)newWordBuf, aWordBuf, 
sizeof(PRUnichar)*(newWordBufSize-moreSize));
5307           }
+                if(newWordBuf) {
5308           moreWidth = ComputeWordFragmentWidth(aPresContext,
5309                                                    aLineBreaker,
5310                                                    aLineLayout,
5311                                                    aReflowState,
5312                                                    aNextFrame, content, tc,
5313                                                    &stop,
5314                                                    newWordBuf,
5315                                                    aWordLen,
5316                                                    newWordBufSize);
5317           NS_ASSERTION((moreWidth >= 0), "ComputeWordFragmentWidth is 
returning negative");
+                } else {
+                  stop = PR_TRUE;
+                  moreWidth = 0;
+                }
5318         }
5319 
5320         NS_RELEASE(tc);
5321         NS_RELEASE(content);
5322         addedWidth += moreWidth;
5323 #ifdef DEBUG_WORD_WRAPPING
5324         printf("  moreWidth=%d (addedWidth=%d) stop=%c\n", moreWidth,
5325                addedWidth, stop?'T':'F');
5326 #endif
5327         if (stop) {
5328           goto done;
5329         }
.....
5344  done:;
5345 #ifdef DEBUG_WORD_WRAPPING
5346   printf("  total word width=%d\n", aBaseWidth + addedWidth);
5347 #endif
5348   if (newWordBuf != aWordBuf)
+         if(newWordBuf)
5349     nsMemory::Free(newWordBuf);

Comment 20

[Roy Yokoyama]

ftang: I was able to reproduce this bug in Win98-CT as well. It crashes at the 
same nsCRT::memcpy(...) 

Comment 21

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

Attachment: Patch #2 (cvs diff -u -w layout/html)

Comment 22

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

Roy,

would you like to try the patch in your build? The file is huge as you might 
have noticed already (~40MB). It still crashes on my machine, when I hit 
the "Stop" button...

Comment 23

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

this is the stack trace from the "onstop" crasher. Roy, are you seeing this as 
well?


nsHttpTransaction::Cancel(nsHttpTransaction * const 0x03ed48a0, unsigned int 
2152398850) line 647 + 12 bytes
nsHttpChannel::Cancel(nsHttpChannel * const 0x03ecc350, unsigned int 
2152398850) line 1590
nsLoadGroup::Cancel(nsLoadGroup * const 0x03983310, unsigned int 2152398850) 
line 239 + 16 bytes
nsDocLoaderImpl::Stop(nsDocLoaderImpl * const 0x03983380) line 278 + 31 bytes
nsURILoader::Stop(nsURILoader * const 0x00ff4f10, nsISupports * 0x03983398) 
line 536 + 23 bytes
nsDocShell::Stop(nsDocShell * const 0x03983ce0) line 2211
XPTC_InvokeByIndex(nsISupports * 0x03983ce0, unsigned int 10, unsigned int 0, 
nsXPTCVariant * 0x0012d4fc) line 139
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode 
CALL_METHOD) line 1881 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x02c272f0, JSObject * 0x027e0d28, unsigned int 
0, long * 0x049da8e8, long * 0x0012d730) line 1252 + 11 bytes
js_Invoke(JSContext * 0x02c272f0, unsigned int 0, unsigned int 0) line 807 + 23 
bytes
js_Interpret(JSContext * 0x02c272f0, long * 0x0012e4d4) line 2702 + 15 bytes
js_Invoke(JSContext * 0x02c272f0, unsigned int 1, unsigned int 2) line 824 + 13 
bytes
js_InternalInvoke(JSContext * 0x02c272f0, JSObject * 0x02766478, long 41816784, 
unsigned int 0, unsigned int 1, long * 0x0012e6ac, long * 0x0012e5fc) line 896 
+ 20 bytes
JS_CallFunctionValue(JSContext * 0x02c272f0, JSObject * 0x02766478, long 
41816784, unsigned int 1, long * 0x0012e6ac, long * 0x0012e5fc) line 3320 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x02c274a0, void * 
0x02766478, void * 0x027e12d0, unsigned int 1, void * 0x0012e6ac, int * 
0x0012e6a8, int 0) line 935 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x0344e860, 
nsIDOMEvent * 0x041cb6c4) line 139 + 57 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x0344e7e0, 
nsIDOMEvent * 0x041cb6c4, nsIDOMEventTarget * 0x0344e918, unsigned int 8, 
unsigned int 7) line 1119 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x0344e8b0, 
nsIPresContext * 0x02cd7aa0, nsEvent * 0x0012f140, nsIDOMEvent * * 0x0012f004, 
nsIDOMEventTarget * 0x0344e918, unsigned int 7, nsEventStatus * 0x0012f188) 
line 2087 + 36 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x0344e910, nsIPresContext * 
0x02cd7aa0, nsEvent * 0x0012f140, nsIDOMEvent * * 0x0012f004, unsigned int 1, 
nsEventStatus * 0x0012f188) line 3631
PresShell::HandleDOMEventWithTarget(PresShell * const 0x02cd62f0, nsIContent * 
0x0344e910, nsEvent * 0x0012f140, nsEventStatus * 0x0012f188) line 5564 + 39 
bytes
nsButtonBoxFrame::MouseClicked(nsIPresContext * 0x02cd7aa0, nsGUIEvent * 
0x0012f33c) line 181
nsButtonBoxFrame::HandleEvent(nsButtonBoxFrame * const 0x027a017c, 
nsIPresContext * 0x02cd7aa0, nsGUIEvent * 0x0012f33c, nsEventStatus * 
0x0012f654) line 128
PresShell::HandleEventInternal(nsEvent * 0x0012f33c, nsIView * 0x00000000, 
unsigned int 1, nsEventStatus * 0x0012f654) line 5532 + 41 bytes
PresShell::HandleEventWithTarget(PresShell * const 0x02cd62f0, nsEvent * 
0x0012f33c, nsIFrame * 0x027a017c, nsIContent * 0x0344e910, unsigned int 1, 
nsEventStatus * 0x0012f654) line 5490 + 22 bytes
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 
0x0365c080, nsIPresContext * 0x02cd7aa0, nsMouseEvent * 0x0012f760, 
nsEventStatus * 0x0012f654) line 2465 + 61 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x0365c088, 
nsIPresContext * 0x02cd7aa0, nsEvent * 0x0012f760, nsIFrame * 0x027a017c, 
nsEventStatus * 0x0012f654, nsIView * 0x02cd7560) line 1550 + 28 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f760, nsIView * 0x02cd7560, 
unsigned int 1, nsEventStatus * 0x0012f654) line 5537 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x02cd62f4, nsIView * 0x02cd7560, 
nsGUIEvent * 0x0012f760, nsEventStatus * 0x0012f654, int 1, int & 1) line 5444 
+ 25 bytes
nsView::HandleEvent(nsView * const 0x02cd7560, nsGUIEvent * 0x0012f760, 
unsigned int 28, nsEventStatus * 0x0012f654, int 1, int & 1) line 377
nsViewManager::DispatchEvent(nsViewManager * const 0x02cd7700, nsGUIEvent * 
0x0012f760, nsEventStatus * 0x0012f654) line 2051
HandleEvent(nsGUIEvent * 0x0012f760) line 68
nsWindow::DispatchEvent(nsWindow * const 0x02cd7424, nsGUIEvent * 0x0012f760, 
nsEventStatus & nsEventStatus_eIgnore) line 715 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f760) line 736
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4223 
+ 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 
4470
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 3670278, long * 
0x0012fba4) line 3194 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x002f026a, unsigned int 514, unsigned int 0, 
long 3670278) line 983 + 27 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x01048750) line 418
main1(int 1, char * * 0x004842d0, nsISupports * 0x00000000) line 1110 + 32 bytes
main(int 1, char * * 0x004842d0) line 1408 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()

Comment 24

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

Oh, it looks like darin addressed the "cancel" issue:

[e-mail]: bug 85822 "crash in [@ nsHttpTransaction::Cancel] 
[cancelation not thread-safe]"
r/sr=blizzard a=blizzard

Comment 25

[Frank Tang]

jbetak- I didn't see the following change in your patch
5348   if (newWordBuf != aWordBuf)
+         if(newWordBuf)
5349     nsMemory::Free(newWordBuf);

Comment 26

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

ftang - you are right, I missed that part of the mod. I'm verifying the patch 
with a fresh build, which also includes Darin's http channel fix, and will 
repost the patch for r/sr shortly.

Comment 27

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

Attachment: Patch #3 (cvs diff -u -w layout/html)

Comment 28

[Frank Tang]

r=ftang

Comment 29

[Chris Waterson]

So, have you verified that this patch *really* fix the crash?
|nsMemory::Alloc()| will return zero if malloc() failed; the stack frame that
you pasted into the bug shows that the destination address is non-zero...

  nsCRT::memcpy(void * 0x02b2aff0, const void * 0x048d7b28, unsigned int 7007)

Comment 30

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

Chris,

thanks for going over this. The crash might have been caused by attempts to 
read beyond aWordBuf's boundary, as we were passing wrong buffer length into 
memcpy. The other changes are a belated attempt to beef up error handling; 
Frank, Roy and I thought it might be a good idea to check them in alongside the 
crasher fix below.

-nsCRT::memcpy((void*)newWordBuf, aWordBuf, sizeof(PRUnichar)*newWordBufSize-
moreSize);

+nsCRT::memcpy((void*)newWordBuf, aWordBuf, sizeof(PRUnichar)*(newWordBufSize-
moreSize));

Comment 31

[Frank Tang]

I believe the current crash we experience is not really the origional bug. But
we need to remove that one before we hit the origional crash
As jbetak said. The patch include other bullet proof code. The real fix for the
latest crash is the '(' and ')' in the nsCRT::memcpy . As you can see,
shanjian's last patch try to do + and - between newWordBufSize, and moreSize .
so while we multiple the sizeof(PRUnichar), we should '(' and ')' the +/- of
newWordBufSize and moreSize first.

Comment 32

[Chris Waterson]

Gotcha. I missed those parens! sr=waterson

Comment 33

[Frank Tang]

wait for a=

Comment 34

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 35

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

checked in - clearing whiteboard status, setting 0.9.3 to keep this on our 
radar as suggested by ftang.

greer, thanks for your email. I'll try to go over the latest talkbacks to see, 
whether things have improved with the latest check-in. Could you assist us in 
verifying this?

Comment 36

[Frank Tang]

move it back to moz0.9.2. I want to make sure we don't crash now. 

Comment 37

[Frank Tang]

to force the verification. I mark this bug fixed since we can no longer 
reproduce this after we remove the blocking crasher. Reopen this bug if you can 
get the same stack trace

Comment 38

[Frank Tang]

The last crash in the same stack signature (nsJISx4501LineBreaker::Next] is 
2001061309 (see 
http://cyclone.mcom.com/reports/searchstacksignature.cfm?stacksig=nsJISx4501Line
Breaker%3A%3ANext )
This could be because roy check in the 72415 which cause the new crash before 
hitting the origional crash. 

Let's keep this close and keep an eye on the http://cyclone.mcom.com . Hopefully 
we won't see any new build ID show in that stack trace. 

Comment 39

[Yuying Long]

I haven't seen the crash on 09-04 trunk build, mark as verified for now.
Please re-open if the crash still occur.