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

VERIFIED FIXED in mozilla1.8alpha5

Status

()

defect
P1
critical
VERIFIED FIXED
15 years ago
5 years ago

People

(Reporter: aha, Assigned: dbaron)

Tracking

(Depends on 1 bug, 4 keywords)

Trunk
mozilla1.8alpha5
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch]re-opened for trunk only., crash signature, URL)

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
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

Comment 2

15 years ago
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

Comment 3

15 years ago
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

Comment 4

15 years ago
req blocking-aviary1.0

btw, there are other crashtests there
http://lcamtuf.coredump.cx/mangleme/gallery/
Flags: blocking-aviary1.0?

Comment 5

15 years ago
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

Updated

15 years ago
Blocks: Zalewski

Comment 6

15 years ago
-> Browser, Parser.

Updated

15 years ago
Component: General → HTML: Parser
Product: Firefox → Browser
Version: 1.0 Branch → 1.7 Branch

Updated

15 years ago
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

Comment 8

15 years ago
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

Updated

15 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Summary: crash [@ nsBlockFrame::PushLines ][@ firefox.exe ] → mangle crash [@ nsBlockFrame::PushLines ][@ firefox.exe ]
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+

Updated

15 years ago
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
Last Resolved: 15 years ago
Priority: -- → P1
Hardware: PC → All
Resolution: --- → FIXED
Whiteboard: has patch. ready to land → [patch]has patch. ready to land
Target Milestone: --- → mozilla1.8alpha5

Updated

15 years ago
Keywords: fixed1.7fixed1.7.x

Comment 13

15 years ago
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.

Comment 14

15 years ago
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 → ---

Comment 16

15 years ago
*** Bug 265967 has been marked as a duplicate of this bug. ***
Whiteboard: [patch]has patch. ready to land → [patch]re-opened for trunk only.

Comment 17

15 years ago
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?

Comment 18

15 years ago
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?

Comment 19

15 years ago
(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

Comment 20

15 years ago
reclosing as fixed, the hang bug looks related to bug 239840, though I might be
wrong. Will post testcase there.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 21

15 years ago
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. ***

Comment 24

10 years ago
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.