Not sure _why_ this is happening but, to reproduce... 1. Remove c:\winnt\mozregistry.dat to force profile manager to run. 2. Start apprunner. 3. Click "finish" in the profile wizard. 4. Apprunner begins to start. 5. You'll crash in the PreferenceChanged() callback, because mShell has not been initialized, and an attempt is made to dereference it. The band-aid fix is to whack the constructor to initialize mShell to null, then check here before attempting to dereference. Not sure if this is symptomatic of a deeper problem. Troy, I'm giving this to you because your fingerprints are all over the nsPresContext::PreferenceChanged() method :-). Hand off as appropriate.

mShell is already set to NULL, because the nsPresContext uses NS_DECL_AND_IMPL_ZEROING_OPERATOR_NEW I added a NULL pointer check in PreferenceChanged for mShell being NULL and that should be fine I don't think there's a bigger issue here. It looks like the pres context hasn't has SetShell called yet which is fine.

*** Bug 13650 has been marked as a duplicate of this bug. ***

I'm still seeing what appears to be the same crash on a 9/15 morning cvs pull (post tree closing) on solaris/egcs. Crash is initiated in the fashion as waterson described, with the following stack trace: Program received signal SIGBUS, Bus error. 0xfd5a70fc in nsPresContext::PreferenceChanged (this=0x235fc0, aPrefName=0x584298 "browser.startup.homepage") at /cs/src/mozilla/mozilla/layout/base/src/nsPresContext.cpp:252 252 mShell->GetRootFrame(&rootFrame); (gdb) p mShell $1 = (nsIPresShell *) 0x2592b0 (gdb) where #0 0xfd5a70fc in nsPresContext::PreferenceChanged (this=0x235fc0, aPrefName=0x584298 "browser.startup.homepage") at /cs/src/mozilla/mozilla/layout/base/src/nsPresContext.cpp:252 #1 0xfd5a6214 in PrefChangedCallback ( aPrefName=0x584298 "browser.startup.homepage", instance_data=0x235fc0) at /cs/src/mozilla/mozilla/layout/base/src/nsPresContext.cpp:53 #2 0xfde0ddbc in pref_DoCallback ( changed_pref=0x584298 "browser.startup.homepage") at /cs/src/mozilla/mozilla/modules/libpref/src/prefapi.c:2313 #3 0xfde0c98c in pref_HashPref (key=0x584298 "browser.startup.homepage", value={stringVal = 0x6a45e0 "www.mozilla.org", intVal = 6964704, boolVal = 6964704}, type=PREF_STRING, action=PREF_SETDEFAULT) at /cs/src/mozilla/mozilla/modules/libpref/src/prefapi.c:1878 #4 0xfde09984 in PREF_SetDefaultCharPref ( pref_name=0x584298 "browser.startup.homepage", value=0x6a45e0 "www.mozilla.org") at /cs/src/mozilla/mozilla/modules/libpref/src/prefapi.c:813 #5 0xfde10878 in nsPref::SetDefaultCharPref (this=0x55c48, pref=0x584298 "browser.startup.homepage", value=0x6a45e0 "www.mozilla.org") at /cs/src/mozilla/mozilla/modules/libpref/src/nsPref.cpp:654 #6 0xff1417cc in XPTC_InvokeByIndex () at ../../../../../../dist/include/xptcstubsdef.inc:142 #7 0xfdeaa3c4 in nsXPCWrappedNativeClass::CallWrappedMethod (this=0x6a6a00, cx=0x144380, wrapper=0x6d2788, desc=0x252680, callMode=CALL_METHOD, argc=2, argv=0x2d3708, vp=0xffbedfcc) at /cs/src/mozilla/mozilla/js/src/xpconnect/src/xpcwrappednativeclass.cpp:661 [munch]

Then there's something wrong with your build. Here's what the changed code looks like: if (mShell) { // Have the root frame's style context remap its style based on the // user preferences nsIFrame* rootFrame; mShell->GetRootFrame(&rootFrame); if (rootFrame) { You can see there's a NULL pointer check...

It's crashing in PreferenceChanged(), but not due to mShell being null. Program received signal SIGBUS, Bus error. 0xfd5a70fc in nsPresContext::PreferenceChanged (this=0x235fc0, aPrefName=0x584298 "browser.startup.homepage") at /cs/src/mozilla/mozilla/layout/base/src/nsPresContext.cpp:252 252 mShell->GetRootFrame(&rootFrame); (gdb) p mShell $1 = (nsIPresShell *) 0x2592b0

Clearing FIXED resolution due to reopen of this bug. Can a Target Milestone be set for this bug please.

Reassigning to apprunner folks. This problem is apprunner only (i.e., it doesn't happen in viewer). 1. the pres context initializes mShell to NULL (see comment about NS_DECL_AND_IMPL_ZEROING_OPERATOR_NEW) 2. I added a NULL pointer check

Ok, I'm seeing this on Linux, as well. 'mShell' is valid, but the 'rootFrame' is pointing to a deleted frame. I think this was what jband was trying to get at: it looks like a preference changed callback is going to a window that just got clobbered.

As leaf noted on IRC, the _second_ time you start apprunner (this time, with a profile) everything will come up nice and happy. Which is why this bug is not holding the tree closed.

*** Bug 13877 has been marked as a duplicate of this bug. ***

*** Bug 13151 has been marked as a duplicate of this bug. ***

Chris, can you check this out?

crash -> critical severity

Pulling into m10.

Appears to crash in a variety of places in PreferenceChanged. I started apprunner about ten times without a profile, and came up with these three different crashes: t@1 (l@1) signal SEGV (no mapping at the fault address) in nsPresContext::PreferenceChanged at line 257 in file "nsPresContext.cpp" 257 rootStyleContext->RemapStyle(this); (dbx) where current thread: t@1 =>[1] nsPresContext::PreferenceChanged(this = 0x2b0538, aPrefName = 0x5bc710 "browser.startup.homepage"), line 257 in "nsPresContext.cpp" [2] PrefChangedCallback(aPrefName = 0x5bc710 "browser.startup.homepage", instance_data = 0x2b0538), line 53 in "nsPresContext.cpp" [munch] t@1 (l@1) signal BUS (invalid address alignment) in nsPresContext::PreferenceChanged at line 256 in file "nsPresContext.cpp" 256 rootFrame->GetStyleContext(&rootStyleContext); (dbx) where current thread: t@1 =>[1] nsPresContext::PreferenceChanged(this = 0x2b6558, aPrefName = 0x5bb8c0 "browser.startup.homepage"), line 256 in "nsPresContext.cpp" [2] PrefChangedCallback(aPrefName = 0x5bb8c0 "browser.startup.homepage", instance_data = 0x2b6558), line 53 in "nsPresContext.cpp" [munch] t@1 (l@1) signal SEGV (no mapping at the fault address) in nsPresContext::PreferenceChanged at line 252 in file "nsPresContext.cpp" 252 mShell->GetRootFrame(&rootFrame); (dbx) where current thread: t@1 =>[1] nsPresContext::PreferenceChanged(this = 0x2b65c8, aPrefName = 0x5bbb98 "browser.startup.homepage"), line 252 in "nsPresContext.cpp" [2] PrefChangedCallback(aPrefName = 0x5bbb98 "browser.startup.homepage", instance_data = 0x2b65c8), line 53 in "nsPresContext.cpp" [munch]

That suggests to me that we have some memory corruptions going on. Now that we actualy free memory, it's not surprising that we would see the effect of FMR and FMW.

*** Bug 14407 has been marked as a duplicate of this bug. ***

mass migration to m11

adding myself to the cc list.

*** Bug 14787 has been marked as a duplicate of this bug. ***

*** Bug 15025 has been marked as a duplicate of this bug. ***

I've got a fix for this, will check in later today.

Johnny Stenback posted a fix to the layout newsgroup. Is this the same fix or a different fix?

a different fix. my fix for this was to properly set up the prefs state upon new profile creation. (it was already being set up properly upon migration.) my part of the fix is in checked in. marking fixed.

Fixed in the Oct 1 build.