Closed Bug 38652 Opened 24 years ago Closed 24 years ago

mozilla crashes with large line of text

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: Marko.Macek, Assigned: buster)

Details

(Keywords: crash, perf, Whiteboard: [NoBlock])

Attachments

(2 files)

crash mozilla on windows
(deleted), application/octet-stream
Details
changes I have to mostly fix painting on Win98 (still need to fix the PRUnichar DrawString)
(deleted), patch
Details | Diff | Splinter Review
I will attach a testcase that crashes mozilla on Windows. (zipped due to size) On linux there seem to be problems with wrapping (also visibile on windows with a reduced test case).
Attached file crash mozilla on windows (deleted) —
This is probably a dup of bug 32334, but this report doesn't provide me with enough details to tell, and the attachment isn't properly encoded so it can't be viewed (reporter must have set the MIME type incorrectly).
Severity: major → critical
Keywords: crash
Assignee: troy → brade
Reassigning to brade based on Blakes comment. Without a working test case or more detailed description of the problem this bug probably should be marked invalid.
The attachment is a .zip file (compressed size is 2k instead 2MB original). I renamed it and it extracted fine on Linux. The bug 32334 is not the same as my text is pure HTML, nothing to do with text boxes. The problem could be related to wrapping because 2MB text on one line seemed to work fine(?). The attached file in .zip has the following contents (more or less): <html> <body> aaa...aaa (about 50 chars) aaaaaaaa...aaaaa (about 2MB <br> (lots of them) </html> On Linux it displays all in one line (no wrapping). On windows it crashes. A smaller test case (I seem to have lost it) also displayed on one line on windows without crash.
reassign back to kmcclusk; this isn't an editor issue since this is in the browser and is an html file with no form fields. please reassign as appropriate btw, on Mac, I don't crash but I don't see any of the lines with "aaaaaaaaa" Could someone help out by trying to simplify the attached testcase? Perhaps remove some of the <br> tags or reduce some of the 'a'?
Assignee: brade → kmcclusk
OS: Windows NT → All
See also bug 38946 for painting problems on Linux.
Removing All <BR> will still make it crash. Removing the first line of 'a' and the last 1,000,000 of 'a' will remove the crash, but will still show invalid wrapping of text. (This is probably a separate bug or just a limit of the layout engine). The text wraps even though there is no whitespace inside.
Confirming bug. It crashes immediately on WINNT when loading this page. Brings up Microsoft VisualC++ Debug Library dialog: DAMAGE:after Normal block (#1482373) at )x03D4A628
Status: UNCONFIRMED → NEW
Ever confirmed: true
crash stack trace _free_dbg_lk(void * 0x03b2e568, int 1) line 1033 + 60 bytes _free_dbg(void * 0x03b2e568, int 1) line 970 + 13 bytes operator delete(void * 0x03b2e568) line 49 + 16 bytes nsAutoTextBuffer::~nsAutoTextBuffer() line 47 + 17 bytes nsTextTransformer::~nsTextTransformer() line 146 + 11 bytes nsTextFrame::Reflow(nsTextFrame * const 0x02d4b2a0, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 4415 + 21 bytes nsLineLayout::ReflowFrame(nsIFrame * 0x02d4b2a0, nsIFrame * * 0x0012e7ac, unsigned int & 0, nsHTMLReflowMetrics * 0x00000000, int & 0) line 971 nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & {...}, nsLineLayout & {...}, nsLineBox * 0x02d744a4, nsIFrame * 0x02d4b2a0, unsigned char * 0x0012dd1c) line 4276 + 29 bytes nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & {...}, nsLineLayout & {...}, nsLineBox * 0x02d744a4, int * 0x0012e3a4, unsigned char * 0x0012e1fc, int 0, int 0) line 4160 + 28 bytes nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState & {...}, nsLineBox * 0x02d744a4, int * 0x0012e3a4, unsigned char * 0x0012e1fc, int 0, int 0) line 4096 + 42 bytes nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & {...}, nsLineBox * 0x02d744a4, int * 0x0012e3a4, int 0, int 0) line 4039 + 32 bytes nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x02d744a4, int * 0x0012e3a4, int 0) line 3192 + 29 bytes nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2885 + 27 bytes nsBlockFrame::Reflow(nsBlockFrame * const 0x02d4b204, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1713 + 15 bytes nsBlockReflowContext::ReflowBlock(nsIFrame * 0x02d4b204, const nsRect & {...}, int 1, int 0, int 1, nsMargin & {...}, unsigned int & 0) line 469 + 45 bytes nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineBox * 0x02d4b278, int * 0x0012edfc) line 3791 + 56 bytes nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x02d4b278, int * 0x0012edfc, int 0) line 3078 + 23 bytes nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2885 + 27 bytes nsBlockFrame::Reflow(nsBlockFrame * const 0x02d4b17c, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1713 + 15 bytes nsContainerFrame::ReflowChild(nsIFrame * 0x02d4b17c, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 643 + 31 bytes CanvasFrame::Reflow(CanvasFrame * const 0x02d4a4ac, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 306 nsBoxToBlockAdaptor::Reflow(nsBoxLayoutState & {...}, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0, int 0, int 0, int 27095160, int 7770, int 1) line 660 nsBoxToBlockAdaptor::Layout(nsBoxToBlockAdaptor * const 0x02d4b124, nsBoxLayoutState & {...}) line 329 + 52 bytes nsScrollPortFrame::Layout(nsScrollPortFrame * const 0x02d4a5c8, nsBoxLayoutState & {...}) line 334 nsContainerBox::LayoutChildAt(nsBoxLayoutState & {...}, nsIBox * 0x02d4a5c8, const nsRect & {...}) line 578 + 16 bytes nsGfxScrollFrameInner::LayoutBox(nsBoxLayoutState & {...}, nsIBox * 0x02d4a5c8, const nsRect & {...}) line 807 nsGfxScrollFrameInner::Layout(nsBoxLayoutState & {...}) line 992 nsGfxScrollFrame::Layout(nsGfxScrollFrame * const 0x02d4a520, nsBoxLayoutState & {...}) line 815 + 15 bytes nsBoxFrame::Reflow(nsBoxFrame * const 0x02d4a4e8, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 678 nsGfxScrollFrame::Reflow(nsGfxScrollFrame * const 0x02d4a4e8, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 551 + 25 bytes nsContainerFrame::ReflowChild(nsIFrame * 0x02d4a4e8, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 643 + 31 bytes ViewportFrame::Reflow(ViewportFrame * const 0x02d4a470, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 546 nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x037067b0, nsIPresContext * 0x036d7cd0, nsHTMLReflowMetrics & {...}, const nsSize & {...}, nsIRenderingContext & {...}) line 145 PresShell::ProcessReflowCommands(int 1) line 3690 ReflowEvent::HandleEvent() line 3582 HandlePLEvent(ReflowEvent * 0x03700ca0) line 3592 PL_HandleEvent(PLEvent * 0x03700ca0) line 575 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x018ae910) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x01f5037e, unsigned int 49399, unsigned int 0, long 25880848) line 1030 + 9 bytes USER32! 77e71820() 018ae910() Looks like mBuffer holds a bad address when it deleted in the destructor of nsAutoTextBuffer. nsAutoTextBuffer::~nsAutoTextBuffer() { if (mBuffer && (mBuffer != mAutoBuffer)) { delete [] mBuffer; } } Reassigning to buster
Assignee: kmcclusk → buster
the test case no longer crashes, but the performance is sure bad. changing "crash" keyword to "perf". This is probably a duplicate. I'm curious to see how this performs after Nisheeth fixes the {ib} problems.
Severity: critical → major
Status: NEW → ASSIGNED
Keywords: crash → perf
Priority: P3 → P2
Target Milestone: --- → M18
Adding crash keyword
Keywords: crash
jan: I had removed the "crash" keyword because the test case no longer crashes, at least for me. Why did you re-add it? Did you find a way to make it crash?
Build 2000051420 still crashes for me immediatelly. I will send another talkback :) (at least a few sent already mentioning this bug).
It used to crash when the status bar showed 19% loaded. Now it crashes at 97% done.
With the Win 32 May 22nd build (2000052208), attempting to load this large txt file in NS6 causes a crash. The crash when status bar reachs 16 %. Both Mac and Linux May 22 builds open this file without crashing.
Per beppe, and edge case. Putting on [NoBlock] radar so we knoe it is not critical to fix at this time.
Whiteboard: [NoBlock]
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M18 → Future
A Windows-only crash sounds like it could have something to do with Troy's text-measurement code. Perhaps this should be split into another bug?
This causes painting problems on Win98 (but I'm pretty sure it wouldn't on NT). I have a fix for that - |nsRenderingContextWin::ConditionRect| needs to do horizontal stuff too. Did anyone else test this on Win9x? (I'm surprised it wasn't mentioned.)
Everyone who is crashing (I'm not on Win98): Are you crashing on Windows NT or Windows 9x? Which version?
I have a crash on NT4SP5. Haven't tried on '98. Linux works fine but has repainting problems (bug 38946 was filed for painting problems)
Does anybody know if kmcclusk's stack trace above is still how this is crashing? Since buster marked this as "Future", I'm going to assign it to myself since I may have time to investigate it a little more.
Assignee: buster → dbaron
Status: ASSIGNED → NEW
PR1 crashes on win98 for me too. (I don't have other builds handy at this time)
On Win98, the one very long line is showing up completely blank. I figured out why this is happening. The documentation at http://msdn.microsoft.com/library/psdk/gdi/fontext_2ks4.htm says that the length passed to ExtTextOut (from nsRenderingContextWin::DrawString) may not exceed 8192 chars on Win95/Win98. The number we were passing was in the low 8100's (below 8192). However, on my laptop experiment has shown that the function fails when the length is greater than 4094 characters. Once I figure out what it setting the length, hopefully I can get it to work better... BTW, I think ExtTextOut is to be implemented by the video driver, so the crashing could even be specific to video drivers. (But don't bother telling me what you have unless I can debug on your machine. :-) Also, I'm interested to know whether current builds are crashing, not PR1.
The changes to DrawString don't really work yet -- they do something weird.
A recent build (soon after M16) crashes on win'98 too.
Marko Macek: Could you submit another talkback report on this? I've figured out how to search the talkback reports by email address of submitter, but I don't see anything you submitted earlier than 6/15, so it might be that the old ones were deleted (unless you used a different email).
... and if you can post the talkback incident ID to this bug that would make it even easier.
for M16: id TB13528012G talkback doesn't seem to work with latest nightly :(
The top of the stack trace (from the talkback report) is: ntdll.dll + 0x1d66e (0x77f7d66e) ntdll.dll + 0x4e17 (0x77f64e17) MSVCRT.dll + 0x1436 (0x78001436) MSVCRT.dll + 0x578c (0x7800578c) nsTextFrame::ComputeTotalWordWidth [d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 4403] nsTextFrame::MeasureText [d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 3951] nsTextFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 4180] nsLineLayout::ReflowFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp, line 971]
For reference for those inside Netscape, the report is: http://cyclone/reports/incidenttemplate.cfm?bbid=13528012
The line number in ComputeTotalWordWidth is as if it should be in ComputeWordFragmentWidth, but that's not what the stack shows. Hmmm...
Crash with current nightly build, the id is TB13575481E. It seem to crash sooner than with M16... (0% done) although that's probably just status display change. this is how the stack looks like from MSDEV NTDLL! 77f7d4b1() NTDLL! 77f64157() NTDLL! 77f64876() MSVCRT! 78001385() _nh_malloc(unsigned int 8192, int 1) line 110 operator new(unsigned int 8192) line 23 + 11 bytes GKHTML! 0176f234() GKHTML! 0176fb51()
I don't know how to fix this crash -- I don't even understand what's happening. So I'm giving this bug back to Steve. I filed the Win9x-specific issues as bug 44854.
Assignee: dbaron → buster
No longer crashes on NT using build from 8/16/2000 - clearing crash keyword and requesting others to verify behavior so we can close it.
Keywords: crash
I don't know if anyone other than the reporter could ever reproduce this. It may well still exist.
Adding crash keyword to all open crashers
Keywords: crash
will examine shortly. accepting back from dbaron, who did lots of good research already.
Status: NEW → ASSIGNED
I've now tested this on Win2K and win98 without a crash. The speed issue remains, as does the incorrect line break. Scrolling horizontally is also not working correctly. I'm closing this bug, and I'll check for bugs about the line layout issue and scrolling problems.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Marking works for me in the Oct 25th builds.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: