Closed Bug 265027 Opened 20 years ago Closed 20 years ago

mangle crash [@ nsBlockFrame::PushLines ][@ firefox.exe ]

Categories

(Core :: Layout: Block and Inline, defect, P1)

Product:
Core
Component:
Layout: Block and Inline
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8alpha5

People

(Reporter: aha, Assigned: dbaron)

References

(Depends on 1 open bug,
URL
)

Details

(4 keywords, Whiteboard: [patch]re-opened for trunk only.)

Crash Data

Attachments

(2 files)

waaaaaaaallllllllllllllllllllpaper
1.53 KB, patch
roc
: review+
roc
: superreview+
mkaply
: approval-aviary+
mkaply
: approval1.7.5+
Details | Diff | Splinter Review
stack trace for the hang with build 20041018
65.98 KB, text/plain
Details
based on http://www.securityfocus.com/archive/1/378632/2004-10-15/2004-10-21/0 Repro: 1. open http://lcamtuf.coredump.cx/mangleme/gallery/mozilla_die2.html and see Firefox crashing File contains: <HTML> <HEAD> <MARQUEE> <TABLE> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <MARQUEE HEIGHT=100000000> <TBODY> Attack of the marquees! Michal Zalewski's comment: Bogus pointer access triggered by a unusual combination of visual elements. Also hangs on trunk. FF 1.0/20041018 -> TB1390093G (but no symbols) FF 1.0PR -> TB1390171Q: nsBlockFrame::PushLines [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 4233] nsBlockFrame::PlaceLine [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 4059] nsBlockFrame::DoReflowInlineFrames [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3530] nsBlockFrame::DoReflowInlineFramesAuto [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3347] nsBlockFrame::ReflowInlineFrames [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3292] nsBlockFrame::ReflowLine [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2451] nsBlockFrame::ReflowDirtyLines [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2098] nsBlockFrame::Reflow [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 817] nsBoxToBlockAdaptor::Reflow [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp, line 884] nsBoxToBlockAdaptor::RefreshSizeCache [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp, line 385] nsBoxToBlockAdaptor::GetPrefSize [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp, line 483] nsSprocketLayout::PopulateBoxSizes [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsSprocketLayout.cpp, line 784] nsSprocketLayout::Layout [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsSprocketLayout.cpp, line 238] nsContainerBox::DoLayout [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsContainerBox.cpp, line 610] nsBox::Layout [d:/builds/tinderbox/firefox-0.10.1/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp, line 1001] ...
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041018 Firefox/1.0 confirming
Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10 Confirmed on linux -> platform: all My talkback ID is: TB1391931G
Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10 Confirmed on linux -> platform: all My talkback ID is: TB1391931G
OS: Windows 2000 → All
req blocking-aviary1.0 btw, there are other crashtests there http://lcamtuf.coredump.cx/mangleme/gallery/
Flags: blocking-aviary1.0?
Mozilla freezes when I visit http://lcamtuf.coredump.cx/mangleme/gallery/mozilla_die2.html Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041018
Blocks: Zalewski
-> Browser, Parser.
Component: General → HTML: Parser
Product: Firefox → Browser
Version: 1.0 Branch → 1.7 Branch
Assignee: firefox → parser
QA Contact: firefox.general → mrbkap
Um... what are people smoking? Comments in bug 264944 clearly say where the issue is, and it's NOT parser.
Assignee: parser → mkaply
Component: HTML: Parser → Layout: BiDi Hebrew & Arabic
QA Contact: mrbkap → zach
Version: 1.7 Branch → Trunk
Assignee: mkaply → nobody
Component: Layout: BiDi Hebrew & Arabic → Layout: Block and Inline
QA Contact: zach → core.layout.block-and-inline
dbaron will look at this to see if we can get something for 1.0... any help from others is welcome. roc, can you help?
Assignee: nobody → dbaron
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Summary: crash [@ nsBlockFrame::PushLines ][@ firefox.exe ] → mangle crash [@ nsBlockFrame::PushLines ][@ firefox.exe ]
Blocks: 265404
Attachment #162987 - Flags: superreview?(roc)
Attachment #162987 - Flags: review?(roc)
Attachment #162987 - Flags: approval1.7.x?
Attachment #162987 - Flags: approval-aviary?
Comment on attachment 162987 [details] [diff] [review] waaaaaaaallllllllllllllllllllpaper <dukes-of-hazzard> yeeeeee-HAW! </dukes-of-hazzard>
Attachment #162987 - Flags: superreview?(roc)
Attachment #162987 - Flags: superreview+
Attachment #162987 - Flags: review?(roc)
Attachment #162987 - Flags: review+
Comment on attachment 162987 [details] [diff] [review] waaaaaaaallllllllllllllllllllpaper a=mkaply for branches
Attachment #162987 - Flags: approval1.7.x?
Attachment #162987 - Flags: approval1.7.x+
Attachment #162987 - Flags: approval-aviary?
Attachment #162987 - Flags: approval-aviary+
Whiteboard: has patch. ready to land
Fix checked in to trunk, 2004-10-22 10:32 -0700. Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-10-22 10:33 -0700. Fix checked in to MOZILLA_1_7_BRANCH, 2004-10-22 10:33 -0700.
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0, fixed1.7
Priority: -- → P1
Hardware: PC → All
Resolution: --- → FIXED
Whiteboard: has patch. ready to land → [patch]has patch. ready to land
Target Milestone: --- → mozilla1.8alpha5
Keywords: fixed1.7 → fixed1.7.x
Can anyone explain why the testcase WFM and the mozilla_die2 link now produces a hang, instead of crash? They seem identical. Is it something about timing? Tested with both a fresh nightly 1.7.x build (2004102306) and a fresh trunk CVS build (approx. 2004102313), both on Windows ME. Not reopening yet, but worried.
Correction. Both links WFM with the 1.7.4 build. Both hang the browser with the CVS trunk build. A regression? Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 265967 has been marked as a duplicate of this bug. ***
Whiteboard: [patch]has patch. ready to land → [patch]re-opened for trunk only.
I don't think this is a hang, just takes very very very long to load, I tried with less <marquee>'s and it takes longer and longer to load, until it looks like a hang. File a new bug? or is there a bug about marquee loading slow already?
Yes, but for yesterday's 1.7.x and Firefox (1.0rc1) builds it opens in an eye blick. So there is certainly an error in the trunk build that needs addressing. Even if the loop that the trunk builds fall in is not really eternal, the result is the same thing as a hang. Especially as this is a possible denial of service web page ambush for mozilla users. Why open a new bug if this has the testcases and information on the different behavior of trunk and branches with (practically) the same patch?
(In reply to comment #18) > Yes, but for yesterday's 1.7.x and Firefox (1.0rc1) builds it opens in an eye > blick. So there is certainly an error in the trunk build that needs addressing. > > Even if the loop that the trunk builds fall in is not really eternal, the result > is the same thing as a hang. Especially as this is a possible denial of service > web page ambush for mozilla users. I'm not saying it's not a bug. > > Why open a new bug if this has the testcases and information on the different > behavior of trunk and branches with (practically) the same patch? it's a different bug from the original report of this bug, and the original bug is now fixed
reclosing as fixed, the hang bug looks related to bug 239840, though I might be wrong. Will post testcase there.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
If the remaining problem is really a dupe, you did the right thing. The original bug is dead and squashed! Verifying FIXED per everything said above plus some common sense.
Status: RESOLVED → VERIFIED
This caused bug 265857
*** Bug 270286 has been marked as a duplicate of this bug. ***
layout/base/crashtests/265027-1.html http://hg.mozilla.org/mozilla-central/rev/b0337b6287f3
Flags: in-testsuite+
Crash Signature: [@ nsBlockFrame::PushLines ] [@ firefox.exe ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: