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

Reporter

Description

•

23 years ago

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)

greer

Reporter

Updated

•

23 years ago

Keywords: crash, qawanted, topcrash

greer

Reporter

Comment 1

•

23 years ago

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

nhottanscp

Comment 2

•

23 years ago

Reassign to ftang, cc to shanjian.

Assignee: nhotta → ftang

nhottanscp

Comment 3

•

23 years ago

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

nhottanscp

Comment 4

•

23 years ago

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.

Frank Tang

Comment 5

•

23 years ago

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.

Frank Tang

Comment 6

•

23 years ago

reassign to yokoyama to work on . P1 moz0.9.2. cc attinasi@netscape.com

Assignee: ftang → yokoyama

Priority: -- → P1

Target Milestone: --- → mozilla0.9.2

Roy Yokoyama

Comment 7

•

23 years ago

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.

Status: NEW → ASSIGNED

Roy Yokoyama

Comment 8

•

23 years ago

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

Andreas Becker

Updated

•

23 years ago

QA Contact: andreasb → ylong

Frank Tang

Comment 9

•

23 years ago

reassign to ftang since we cannot reproduce this on window.

Assignee: yokoyama → ftang

Status: ASSIGNED → NEW

greer

Reporter

Comment 10

•

23 years ago

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.

Frank Tang

Comment 11

•

23 years ago

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

Frank Tang

Comment 12

•

23 years ago

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

Assignee: ftang → jbetak

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 13

•

23 years ago

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

Status: NEW → ASSIGNED

Frank Tang

Updated

•

23 years ago

Whiteboard: block-because-cannot-reproduce

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 14

•

23 years ago

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.

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 15

•

23 years ago

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

Frank Tang

Comment 16

•

23 years ago

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.

Whiteboard: block-because-cannot-reproduce

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 17

•

23 years ago

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...

Frank Tang

Comment 18

•

23 years ago

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.

Frank Tang

Comment 19

•

23 years ago

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);

Roy Yokoyama

Comment 20

•

23 years ago

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

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 21

•

23 years ago

Attached patch Patch #2 (cvs diff -u -w layout/html) — Details — Splinter Review

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 22

•

23 years ago

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...

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 23

•

23 years ago

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

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 24

•

23 years ago

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

darin@netscape.com: bug 85822 "crash in [@ nsHttpTransaction::Cancel] 
[cancelation not thread-safe]"
r/sr=blizzard a=blizzard

Frank Tang

Comment 25

•

23 years ago

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

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 26

•

23 years ago

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.

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 27

•

23 years ago

Attached patch Patch #3 (cvs diff -u -w layout/html) — Details — Splinter Review

Frank Tang

Comment 28

•

23 years ago

r=ftang

Frank Tang

Updated

•

23 years ago

Whiteboard: r=ftang need sr= and a=

Chris Waterson

Comment 29

•

23 years ago

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)

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 30

•

23 years ago

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));

Frank Tang

Comment 31

•

23 years ago

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.

Chris Waterson

Comment 32

•

23 years ago

Gotcha. I missed those parens! sr=waterson

Frank Tang

Comment 33

•

23 years ago

wait for a=

Whiteboard: r=ftang need sr= and a= → r=ftang sr=waterson and a= 6/19 9:40

Asa Dotzler [:asa]

Comment 34

•

23 years ago

a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)

Blocks: 83989

Frank Tang

Updated

•

23 years ago

Whiteboard: r=ftang sr=waterson and a= 6/19 9:40 → wait for tree open to check in

jbetak@netscape.com (away - not reading bugmail)

Assignee

Comment 35

•

23 years ago

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?

Whiteboard: wait for tree open to check in

Target Milestone: mozilla0.9.2 → mozilla0.9.3

Frank Tang

Comment 36

•

23 years ago

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

Target Milestone: mozilla0.9.3 → mozilla0.9.2

Frank Tang

Comment 37

•

23 years ago

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

Status: ASSIGNED → RESOLVED

Closed: 23 years ago

Resolution: --- → FIXED

Frank Tang

Comment 38

•

23 years ago

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.

jbetak@netscape.com (away - not reading bugmail)

Assignee

Updated

•

23 years ago

Blocks: 85206

Yuying Long

Comment 39

•

23 years ago

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

Status: RESOLVED → VERIFIED

Nobody; OK to take it and work on it

Updated

•

13 years ago

Crash Signature: [@ nsJISx4501LineBreaker::Next]

Peter Bylenga [:PBylenga]

Updated

•

10 years ago

Keywords: qawanted

Patch #2 (cvs diff -u -w layout/html) 23 years ago jbetak@netscape.com (away - not reading bugmail) 1.62 KB, patch		Details \| Diff \| Splinter Review
Patch #3 (cvs diff -u -w layout/html) 23 years ago jbetak@netscape.com (away - not reading bugmail) 1.97 KB, patch		Details \| Diff \| Splinter Review