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

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Joonas]

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

Comment 1

[Joonas]

Attachment: 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.

Comment 2

[Joonas]

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.

Comment 3

[Ryan Jones-Ward [:sciguyryan]]

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

Comment 4

[Joonas]

Does test 31944 crash for you?
http://127.0.0.1:8080/ruby/iexploder.cgi?lookup=1&test=31944&subtest=

Comment 5

[Joonas]

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.

Comment 6

[Jesse Ruderman]

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

[Jesse Ruderman]

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

[Adam Guthrie]

Joonas, FYI, 127.0.0.1 is only viewable from /your/ system.

Comment 9

[Joonas]

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.

Comment 10

[Jesse Ruderman]

Attachment: 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

[Jesse Ruderman]

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

Comment 12

[Jesse Ruderman]

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

Comment 13

[Daniel Veditz [:dveditz]]

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).

Comment 14

[Joonas]

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?

Comment 15

[Joonas]

Marking fixed, probably by bug 348510.