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
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.
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.
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
Does test 31944 crash for you? http://127.0.0.1:8080/ruby/iexploder.cgi?lookup=1&test=31944&subtest=
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
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?
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.)
Joonas, FYI, 127.0.0.1 is only viewable from /your/ system.
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.
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] ...
Does nonsense on the stack below PL_HandleEvent scare us, or is it normal for Talkback to get confused there?
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).
Summary: Crash with iExploder test 31944 [@ nsHTMLReflowState::ComputePadding] → Crash with iExploder test 31944 [@ nsHTMLReflowState::ComputePadding] [@ nsCachedStyleData::GetStyleData]
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?
Marking fixed, probably by bug 348510.
Status: NEW → RESOLVED
Last Resolved: 12 years ago → 12 years ago
Resolution: --- → FIXED
Crash Signature: [@ nsHTMLReflowState::ComputePadding] [@ nsCachedStyleData::GetStyleData]
You need to log in before you can comment on or make changes to this bug.