Trunk M099 crashes changing prefs [@ nsCSSFrameConstructor::ConstructDocElementFrame

RESOLVED DUPLICATE of bug 77716

Status

()

Core
CSS Parsing and Computation
--
critical
RESOLVED DUPLICATE of bug 77716
17 years ago
17 years ago

People

(Reporter: greer, Assigned: dbaron)

Tracking

({crash, testcase, topcrash+})

Trunk
x86
All
crash, testcase, topcrash+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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
(Reporter)

Updated

17 years ago
Keywords: crash, testcase, topcrash+

Updated

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

Comment 3

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

Updated

17 years ago
Keywords: nsbeta1
(Reporter)

Comment 4

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

Comment 5

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 6

17 years ago
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
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.