Closed Bug 130756 Opened 23 years ago Closed 23 years ago

Trunk M099 crashes changing prefs [@ nsCSSFrameConstructor::ConstructDocElementFrame

Categories

(Core :: CSS Parsing and Computation, defect)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 77716

People

(Reporter: greer, Assigned: dbaron)

References

Details

(Keywords: crash, testcase, topcrash+)

The M099 and the Trunk show this signature in the topcrash reports. I'm not finding a similar open crash with a similar stack, but I am more than happy to have this one duped if I am overlooking one. I have consistently reproduced this crash on Win2000 using the M099 release. 1. View -> Apply Theme -> Get New Theme 2. Get a new theme (I chose star trek and deselected the "Use this theme" checkbox) 3. After downloading, View -> Apply theme -> star trek 4. View -> Apply Theme -> Theme Preferences 5. Appearance -> Fonts 6. Change the sizes of the fonts from the pulldowns. 7. Click OK -> Crash. I have not been able to crash without first switching themes during the current session. nsCSSFrameConstructor::ConstructDocElementFrame [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp line 3121] nsCSSFrameConstructor::ReconstructDocElementHierarchy [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp line 7223] StyleSetImpl::ReconstructDocElementHierarchy [d:\builds\seamonkey\mozilla\content\base\src\nsStyleSet.cpp line 1434] PresShell::ReconstructFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5208] PresShell::SetPreferenceStyleRules [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 2079] nsPresContext::PreferenceChanged [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp line 660] nsPresContext::PrefChangedCallback [d:\builds\seamonkey\mozilla\layout\base\src\nsPresContext.cpp line 105] pref_DoCallback [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.cpp line 1345] pref_HashPref [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.cpp line 1109] PREF_SetIntPref [d:\builds\seamonkey\mozilla\modules\libpref\src\prefapi.cpp line 603] nsPrefBranch::SetIntPref [d:\builds\seamonkey\mozilla\modules\libpref\src\nsPrefBranch.cpp line 257] nsPrefService::SetIntPref [d:\builds\seamonkey\mozilla\modules\libpref\src\nsPrefService.h line 57] nsPref::SetIntPref [d:\builds\seamonkey\mozilla\modules\libpref\src\nsPref.cpp line 245] XPTC_InvokeByIndex [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp line 106] XPCWrappedNative::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp line 2027] XPC_WN_CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp line 1267] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 790] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 2746] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 806] js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c line 881] JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c line 3390] nsJSContext::CallEventHandler [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp line 1019] GlobalWindowImpl::RunTimeout [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp line 4125] GlobalWindowImpl::TimerCallback [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp line 4437] nsTimerImpl::Process [d:\builds\seamonkey\mozilla\xpcom\threads\nsTimerImpl.cpp line 330] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1072] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp line 309] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1305] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1640] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp line 1658] WinMainCRTStartup() KERNEL32.DLL + 0x17d08 (0x77e97d08) Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/style/src/nsCSSF rameConstructor.cpp line : 3121 Comments: M099 (nsCSSFrameConstructor::ConstructDocElementFrame): 26 total (3938897) - 2002031106 [Windows 98 4.10 build 67766222]: Setting preferences URL: When I tried to change 'Serif font' it suddenly crashed. (3957856) - 2002031106 [Windows NT 4.0 build 1381]: I switched it to 'use system colours' in the appearance dialog box. That Appearance seems to have a big bug :-) (3962951) - 2002031106 [Windows NT 5.0 build 2195]: Preferences Dialog URL: Setting my preferences the first time running mozilla. (3963902) - 2002031106 [Windows NT 5.0 build 2195]: Download the star trek theme (3964703) - 2002031106 [Windows NT 5.1 build 2600]: skin preferences (3975220) - 2002031106 [Windows NT 5.0 build 2195]: Changed font size via preferences; serif 16 to serif 14 sans serif 13 to 12 (3978548) - 2002031106 [Windows NT 4.0 build 1381]: Turned off the "Use System Colors" in Edit/Pref erences/Appearance/Colors. I turned this on earlier with no problems. (3979787) - 2002031106 [Windows NT 5.1 build 2600]: saving preferences (3980237) - 2002031106 [Windows NT 5.0 build 2195]: after changes in preferences (3999079) - 2002031106 [Windows NT 5.0 build 2195]: Opened preferences appearance fonts changed standard form sans serif to serif --> bang. (3999329) - 2002031106 [Windows NT 5.0 build 2195]: applying a new theme (3999466) - 2002031106 [Windows NT 5.0 build 2195]: Changing preferences (3939113) - 2002031008 [Linux 2.4.16-4GB]: I changed the display resolution to 96dpi while having the brower and a help window open. (3953104) - 2002031008 [Linux 2.4.10-4GB]: I changed the theme in the preferences dialog from my brand new installed Little Mozilla theme to the modern theme. (3963398) - 2002031008 [Linux 2.4.16-4GB]: just installed 0.9.9 rm'd ~/.mozilla downloaded a couple of theamschanged default home page checked out font settings no changes saved and BANG (3971293) - 2002031008 [Linux 2.5.6-pre1]: I was fiddling with resetting the font dpi in the config box after changing my browser theme to littlemozilla. (4000067) - 2002031008 [Linux 2.4.2-2]: trying to change fonts in preferences to one of the lucida fonts
Depends on: 127784
It looks like the crash is on the line: gfxScrollbarFrame1->GetContent(getter_AddRefs(content)); within: // ----- reattach gfx scrollbars ------ // Gfx scrollframes were created in the root frame but the primary frame map m // new style sheet was loaded so lets reattach the frames to their content. if (mGfxScrollFrame) { nsIFrame* scrollPort = nsnull; mGfxScrollFrame->FirstChild(aPresContext, nsnull, &scrollPort); nsIFrame* gfxScrollbarFrame1 = nsnull; nsIFrame* gfxScrollbarFrame2 = nsnull; nsresult rv = scrollPort->GetNextSibling(&gfxScrollbarFrame1); rv = gfxScrollbarFrame1->GetNextSibling(&gfxScrollbarFrame2); nsCOMPtr<nsIContent> content; gfxScrollbarFrame1->GetContent(getter_AddRefs(content)); aState.mFrameManager->SetPrimaryFrameFor(content, gfxScrollbarFrame1); gfxScrollbarFrame2->GetContent(getter_AddRefs(content)); aState.mFrameManager->SetPrimaryFrameFor(content, gfxScrollbarFrame2); } This seems like a duplicate of bug 77716, which should perhaps be reopened, although these steps to reproduce might be easier to reproduce. I suspect that this is only reproducable with themes other than Modern or Classic that have incorrect scrollbar bindings that don't have the magic ID (i forget what it is) that causes the scrollbar binding to load synchronously.
This could also have something to do with the XBL binding code in FlushMiscWidgetInfo (see bug 121055), which the current patch in bug 121055 does not change.
With dynamic theme switching disabled, the crash originally reported should not happen any more. As Tom said: "I have not been able to crash without first switching themes during the current session." However, I don't think this problem is only with themes...since many of the comments from Mozilla 0.9.9 users mention setting other preferences. I'm going to change the summary to reflect that. There are other recent crashes with this stack signature, but looking at their stack traces they seem to point to bug 77716 (which I will reopen).
Summary: Trunk M099 crashes changing prefs in "Theme Preferences" [@ nsCSSFrameConstructor::ConstructDocElementFrame → Trunk M099 crashes changing prefs [@ nsCSSFrameConstructor::ConstructDocElementFrame
Keywords: nsbeta1
The talkback data shows 57 crashes under this signature from builds on 4/3. (There is only one other Trunk crash at this signature, on a 3/29 build.) However, they are uniformly startup crashes - not this stack, not this bug. No comments mention refs changes. I'll add the info to bug 77716 (same stack) that David/Jay mention above.
Closing this one out as worksforme... There have not been any crashes with this particular stack trace with recent MozillaTrunk builds. All recent crashes with the nsCSSFrameConstructor::ConstructDocElementFrame stack signature have stacks that point to bug 77716.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
I'd rather mark it as duplicate so it points to the comments here.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
*** This bug has been marked as a duplicate of 77716 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.