1.88 KB, text/plain
12.85 KB, text/plain
64.03 KB, text/html
1.04 KB, text/plain
2.97 KB, text/plain
1.52 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041023 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041023 Firefox/1.0 New profile with no extensions and disabled java to simplify testing. Generated random html and opened it with mozilla. Ten minutes later the browser crashed. Verified with the following UA's and sent talkback for each. Testcase to follow. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041023 Firefox/1.0 TB1491736K Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041023 TB1491698Q Reproducible: Always Steps to Reproduce: 1. Disable java 2. View attached testcase 3. Actual Results: Crash Expected Results: No crash
adding keywords crash and testcase
Keywords: crash, testcase
When opening the testcase directly from bugzilla I didn't experience the crash. I saved it locally and viewed it and then I was able to reproduce the crash. I expect your mileage may vary.
testcase is a 64 KB sized file containing random junk, can you reduce it? Link to the two talkback reports and others with same signature: 34 reports with stack signature nsBlockFrame::ReflowFloat http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsBlockFrame%3A%3AReflowFloat&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
OS: Windows XP → All
QA Contact: general → core.layout
Summary: Crash with malformed html → Crash with malformed html [@ nsContainerFrame::PositionChildViews]
(In reply to comment #4) > testcase is a 64 KB sized file containing random junk, can you reduce it? Is it necessary to reduce it further since there is a trace attached to the bug? If so, I can try to reduce it further... it was over 150 KB before I trimmed it down and the returns were diminishing.
The testcase is not random junk - it's UTF-16 encoded. I used validator.w3.org to show the source (at the end): http://validator.w3.org/check?uri=https%3A%2F%2Fbugzilla.mozilla.org%2Fattachment.cgi%3Fid%3D163207%26action%3Dview&charset=%28detect+automatically%29&ss=1 Or you can use "View Source" in an older Mozilla that does not crash - Mozilla 1.0.2 for example. A non-UTF-16 testcase that triggers the crash would be appreciated.
(In reply to comment #8) > A non-UTF-16 testcase that triggers the crash would be appreciated. I have been unable to save the testcase as UTF-8 and reproduce the crash. One thing I have noticed is that the latest Firefox Aviary tends to crash more often with UTF-16 files than the latest Mozilla. In most cases it occurs when navigating away from the page after it was loaded. The attached testcase was the only example I have been able to produce that also crashes the latest Mozilla.
Both crashes from comment 0 have as stack signature nsBlockFrame::ReflowFloat, so I'm a little bit confused about the summary.
The crash is because we use a deleted frame (mContent = 0xdddddddd), my crash data is from a Linux debug build, the talkbacks are from a Windows Opt build so they can differ when the problem first surface. In debug builds we overwrite deleted frames with the pattern above to make memory problems easier to spot. (See FrameArena::FreeFrame() in nsPresShell.cpp).
Summary: Crash with malformed html [@ nsContainerFrame::PositionChildViews] → Crash with malformed html [@ nsContainerFrame::PositionChildViews] [@ nsBlockFrame::ReflowFloat]
Yes, a minimal testcase would help a lot here.... it's very difficult to debug crashes of this sort on huge pages.
I was going to try to reduce the testcase, but I can't make the existing testcase crash in either FF 1.0RC1 or a 20041027 trunk build, PC/WinXP.
It seems that as soon as the file is smaller than 64 KB it stops crashing for me. I have had a little luck with replacing sections of garbage with exact copies of repeating garbage towards the start of the file but it still stops crashing as soon as it gets below 64 KB. I'll continue to try but I don't believe I will be able to reduce it in size though I believe it may be possible to make at least some of the garbage repeating.
So does using 64000 letter 'a's crash? What about 64000 spaces? That is, are the exact bytes used relevant? Or just the number of bytes?
(In reply to comment #15) > So does using 64000 letter 'a's crash? What about 64000 spaces? That is, are > the exact bytes used relevant? Or just the number of bytes? Using 64000 a's or spaces does not crash. Some of the bytes appear to be relevant though not all... I am able to replace large sections with repeating a's or spaces and still cause a crash as long as the file size is above 64 KB. I will continue replacing sections with a's in an attempt to simplify the testcase.
Created attachment 164129 [details] Testcase Better testcase using a's in a div to fill in the file so a crash will occur with the following at the end. Note: I noticed that a crash will not occur if there is one less a or 8 more a's and Java must be disabled for this to crash as with bug 265986. <APPLET VSPACE="124602258205"></APPLET> <DIV>1</DIV> <LI STYLE="FLOAT:LEFT;"></LI>
Attachment #163207 - Attachment is obsolete: true
bug 265986 also mentions java disabled
Regression window: 2004102205 -- 2004102305, after backing out bug 265027 it does not crash (I removed "aState.mBottomEdge != NS_UNCONSTRAINEDSIZE" but kept "!aUpdateMaximumWidth"). The problem is that there is a continuation created for BODY and for some reason the placeholder(LI) remains in the first block whereas the float is on the second (next-in-flow), then since the next-in-flow is empty (no lines) it gets wiped. At least that's what I think happens... See the attachment that follows.
Keywords: qawanted → regression
Since this is a regression, we should try to get it fixed for 1.8 but not going to block the alpha on this.
Flags: blocking1.8a6? → blocking1.8a6-
Created attachment 170771 [details] [diff] [review] fix? This patch is untested (I'm still building). The basic idea is sound --- we should never make continuations when the height is unconstrained, even if integer overflows make it look like we've exceeded the available height. We may just continue on to crash some other way, though. The only really good general solution that I can think of is to complete the switch to floats in layout. Comments appreciated...
13 years ago
Assignee: nobody → roc
Status: NEW → ASSIGNED
The fix that caused this regression was from one of the Zalewski's generated html crashes and this testcase was discovered / created in a similar manner. Unless there appears to be other crashes occurring due to reasons other than generated html that fixing this will fix I would hope no one would spend any time on fixing this bug especially with the proper solution being the switch to using floats. I expect there would also be a chance of this fix causing another regression as bug 265027 caused this one though I may very well be mistaken in this.
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b) Gecko/20050116 tested both testcases, Reload and Shift-Reload, multiple times. looking at the second testcase, may be related to the working of bug 255120
wfm as well with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050117 Firefox/1.0+ Checked both testcases with java turned off per the steps to reproduce as well as with java turned on.
This crash is easy to reproduce with both attached testcases using a debug build. After applying the attached patch I could not make it crash.
13 years ago
Comment on attachment 170771 [details] [diff] [review] fix? r+sr=bzbarsky
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Crash Signature: [@ nsContainerFrame::PositionChildViews] [@ nsBlockFrame::ReflowFloat]
You need to log in before you can comment on or make changes to this bug.