Crash with iExploder test 31944 [@ nsHTMLReflowState::ComputePadding] [@ nsCachedStyleData::GetStyleData]

RESOLVED FIXED

Status

()

--
critical
RESOLVED FIXED
12 years ago
8 years ago

People

(Reporter: j.moz, Unassigned)

Tracking

({crash, testcase})

1.8 Branch
crash, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060724 BonEcho/2.0b1

Bon Echo (Firefox 2.0) branch builds crash with iExploder test 31944.
http://127.0.0.1:8080/ruby/iexploder.cgi?lookup=1&test=31944&subtest=

Trunk builds don't crash.

TB21354255Y
(Reporter)

Comment 1

12 years ago
Created attachment 230448 [details]
testcase (crashes Bon Echo)

The test case is a bit silly, but I couldn't reduce it any more. If I change pretty much anything, it stops crashing.
(Reporter)

Comment 2

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060724 Minefield/3.0a1

Trunk doesn't crash. Bon Echo does.
(Reporter)

Updated

12 years ago
Blocks: 316894
No crash here on branch nightlies?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060724 BonEcho/2.0b1 - Build ID: 2006072408
(Reporter)

Comment 4

12 years ago
Does test 31944 crash for you?
http://127.0.0.1:8080/ruby/iexploder.cgi?lookup=1&test=31944&subtest=
(Reporter)

Comment 5

12 years ago
Oops, false alarm, I guess. I tried to reproduce this with a fresh profile and the crash was gone.

I guess an earlier crash had corrupted my profile, but I guess we'll never know which or how.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID

Comment 6

12 years ago
It's also possible that this is a real bug.  Maybe this bug can only be reproduced if you have certain plugin-related options, for example.

Can you figure out which file(s) from your profile need to be present for the crash to occur?

Comment 7

12 years ago
Or maybe it depends on the width of your browser window.  (That seems likely to me because the crash goes away for you if you remove some of the 'a's in the testcase.)

Comment 8

12 years ago
Joonas, FYI, 127.0.0.1 is only viewable from /your/ system.
(Reporter)

Comment 9

12 years ago
Doh, I meant to link to http://toadstool.se/software/iexploder/demo/iexploder.cgi?lookup=1&test=31944&subtest=  .

And yes, I can crash again if I maximize my browser window (screen resolution 1280x1024).

Thanks for your help. Reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 10

12 years ago
Created attachment 230684 [details]
stack trace from the Talkback ID in comment 0

nsHTMLReflowState::ComputePadding  [nsHTMLReflowState.cpp, line 2440]
nsHTMLReflowState::InitConstraints  [nsHTMLReflowState.cpp, line 1759]
nsHTMLReflowState::Init  [nsHTMLReflowState.cpp, line 342]
nsHTMLReflowState::nsHTMLReflowState  [nsHTMLReflowState.cpp, line 217]
...

Comment 11

12 years ago
Does nonsense on the stack below PL_HandleEvent scare us, or is it normal for Talkback to get confused there?

Comment 12

12 years ago
Confirmed with a Bon Echo nightly on Mac.  I had to fiddle with the size of the window a little to crash, but it did crash and with the same signature.  TB21427822Y
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout
Hardware: PC → All
Version: 2.0 Branch → 1.8 Branch
I can confirm Jesse's results on windows: had to fiddle with the window size, reload, and boom. Same stack in a debug build except the bit above PL_HandleEvent made more sense. Appears to be a null dereference (or 0x00000020 actually: the nsStyleContext is null, and we try to use its mCachedStyleData member at).

Updated

12 years ago
Summary: Crash with iExploder test 31944 [@ nsHTMLReflowState::ComputePadding] → Crash with iExploder test 31944 [@ nsHTMLReflowState::ComputePadding] [@ nsCachedStyleData::GetStyleData]
(Reporter)

Updated

12 years ago
Severity: normal → critical
Depends on: 348510
(Reporter)

Comment 14

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061111 BonEcho/2.0

1.8.1 branch builds don't seem to crash anymore, fixed by bug 348510?
(Reporter)

Comment 15

12 years ago
Marking fixed, probably by bug 348510.
Status: NEW → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

8 years ago
Crash Signature: [@ nsHTMLReflowState::ComputePadding] [@ nsCachedStyleData::GetStyleData]
You need to log in before you can comment on or make changes to this bug.