Closed Bug 13063 Opened 25 years ago Closed 25 years ago

Doing a view source causes a crash

Categories

(Core :: Layout, defect, P1)

x86
Windows NT
defect

Tracking

()

VERIFIED DUPLICATE of bug 9337

People

(Reporter: kmcclusk, Assigned: ftang)

References

()

Details

Attachments

(1 file)

Go to the URL above Do a view source. It crashes, I don't get a stack trace. I assume that's because the crash happens in a different thread. Rick G. Traced a lockup to the content sink's DidBuildModel. When the reflow gets called it locks up.
Also crashes on Win98. I'm at home now, but will check on Mac and Linux tomorrow.
Attached file The test case is actully a huge word. (deleted) —
Assignee: harishd → ftang
Component: Parser → Layout
Priority: P3 → P1
Ok, this is what I found out: We are crashing in nsTextFrame::ComputeWordFragmentWidth()on doing a memcpy. Sorry, no stack available!!. This is because the copy length is exceeding the buffer length and therefore resulting in out of bounds. Frank, you must have got the variables wrong in computing "copylen". Here is the piece of code where you take a look at: // we need to adjust the length by look at the two pieces together PRUint32 copylen = 2*( ((wordLen + aWordBufLen) > aWordBufSize) ? (aWordBufSize - aWordBufLen) : wordLen ); if(copylen > 0) { nsCRT::memcpy((void*)&(aWordBuf[aWordBufLen]), buf, copylen); .... } In the above code aWordBufSize could be less than aWordBufLen and therefore could result in a negative value for copylen. Assigning bug to ftang.
Adding myself to the CC list.
Status: NEW → ASSIGNED
Target Milestone: M11
I am stupid, I use a PRUint32 copylen here and do a if(copylen>0) check and hope it will catch the case aWordBufSize < aWordBufLen. I should change it to // we need to adjust the length by look at the two pieces together PRUint32 copylen = 2*( ((wordLen + aWordBufLen) > aWordBufSize) ? ((aWordBufSize>aWordBufLen)?
fix and check in nsTextFrame.cpp
Linux build ID 99090314 - crashes just going to the page MacPPC build ID 1999090313 - works fine on both the original URL, and the attachment test
I pulled and build fresh this afternoon, and I'm seeing the crash on Linux too. Here is a stack trace from a build - you'll notice that inside nsTextFrame::ComputeWordFragmentWidth, copylen is 4294967260. This is because this line: // we need to adjust the length by look at the two pieces together 2931 PRUint32 copylen = 2*( ((wordLen + aWordBufLen) > aWordBufSize) ? 2932 (aWordBufSize - aWordBufLen) : 2933 wordLen 2934 ); Coming here, wordLen is 4, aWordBugLen is 118, and aWordBugSize is 100. (wordLen+aWordBufLen)>aWordBugSize is true aWordBufSize - aWordBugLen = -18 Since copylen is a PRUint32, this is overflowing to the aforementioned huge number, and causing a crash! #0 0x404ebf87 in memcpy (dstpp=0xbfffdd58, srcpp=0xbfffd354, len=4294967260) at ../sysdeps/generic/memcpy.c:55 #1 0x40161feb in nsCRT::memcpy (aDest=0xbfffdd58, aSrc=0xbfffd354, aCount=4294967260) at ../../dist/include/nsCRT.h:100 #2 0x417b2c3b in nsTextFrame::ComputeWordFragmentWidth (this=0x82e7f08, aPresContext=0x829ade0, aLineLayout=@0xbfffdfc8, aReflowState=@0xbfffde3c, aTextFrame=0x82e8660, aText=0x82ed970, aStop=0xbfffdb64, aWordBuf=0xbfffdc6c, aWordBufLen=@0xbfffdb98, aWordBufSize=100) at nsTextFrame.cpp:2937 #3 0x417b28a6 in nsTextFrame::ComputeTotalWordWidth (this=0x82e7f08, aPresContext=0x829ade0, aLineLayout=@0xbfffdfc8, aReflowState=@0xbfffde3c, aNextFrame=0x82e8660, aBaseWidth=11506, aWordBuf=0xbfffdc6c, aWordBufLen=118, aWordBufSize=100) at nsTextFrame.cpp:2835 #4 0x417b1ffb in nsTextFrame::Reflow (this=0x41781bc4, aPresContext=@0x4177c8e4, aMetrics=@0x4177bbc0, aReflowState=@0xbfffd3f0, aStatus=@0x41991dcd) at nsTextFrame.cpp:2571 #5 0x4177e938 in nsFrame::GetNextSibling (this=0xe853, aNextSibling=0x815b0000) at nsFrame.cpp:1378 #6 0x565760ec in ?? ()
Opps, I just noticed that the checking occured *just* after my build...
Well, since I've already pointed out the obvious, I just pulled Frank's fix and rebuilt. The fix works for both test cases. I'd say go ahead and mark this one fixed!
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 9337 ***
Status: RESOLVED → VERIFIED
also fixed.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: