873831 - crash in mozilla::Preferences::Add(Uint|Bool)VarCache

Status: RESOLVED DUPLICATE of bug 1276488

(Core :: Preferences: Backend, defect)

Description

[Scoobidiver (away)]

It's a startup crash likely related to an extension that is not fully loaded at the time of the crash so we don't know which one is.
It's currently #31 crashes in 22.0b1 with many duplicates.

Depending on the channel, the stack trace is:
Frame 	Module 	Signature 	Source
0 	xul.dll 	nsTArray_Impl<nsAutoPtr<mozilla::CacheData>,nsTArrayInfallibleAllocator>::Append 	obj-firefox/dist/include/nsTArray.h:1033
1 	xul.dll 	mozilla::Preferences::AddUintVarCache 	modules/libpref/src/Preferences.cpp:1589
2 	xul.dll 	mozilla::AvailableMemoryTracker::Activate 	xpcom/base/AvailableMemoryTracker.cpp:584
3 	xul.dll 	NS_InitXPCOM2 	xpcom/build/nsXPComInit.cpp:481
4 	xul.dll 	ScopedXPCOMStartup::Initialize 	toolkit/xre/nsAppRunner.cpp:1183
5 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3931
6 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:4140
7 	firefox.exe 	do_main 	browser/app/nsBrowserApp.cpp:273
8 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:105
9 	firefox.exe 	__tmainCRTStartup 	crtexe.c:552
10 	kernel32.dll 	BaseProcessStart 

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsTArray_Impl<nsAutoPtr<mozilla::CacheData>,nsTArrayInfallibleAllocator>::Append 	obj-firefox/dist/include/nsTArray.h:1044
1 	xul.dll 	mozilla::Preferences::AddBoolVarCache 	modules/libpref/src/Preferences.cpp:1543
2 	xul.dll 	nsCSSPseudoClasses::AddRefAtoms 	layout/style/nsCSSPseudoClassList.h:111
3 	xul.dll 	nsLayoutStatics::Initialize 	layout/build/nsLayoutStatics.cpp:146
4 	xul.dll 	Initialize 	layout/build/nsLayoutModule.cpp:405
5 	xul.dll 	nsComponentManagerImpl::KnownModule::Load 	xpcom/components/nsComponentManager.cpp:766
6 	xul.dll 	nsFactoryEntry::GetFactory 	xpcom/components/nsComponentManager.cpp:1774
7 	xul.dll 	nsComponentManagerImpl::CreateInstanceByContractID 	xpcom/components/nsComponentManager.cpp:1089
8 	xul.dll 	nsComponentManagerImpl::GetServiceByContractID 	xpcom/components/nsComponentManager.cpp:1449
9 	xul.dll 	nsCOMPtr_base::assign_from_gs_contractid 	obj-firefox/xpcom/build/nsCOMPtr.cpp:92
10 	xul.dll 	nsCOMPtr<nsISupports>::nsCOMPtr<nsISupports> 	xpcom/glue/nsCOMPtr.h:956
11 	xul.dll 	NS_InitXPCOM2 	xpcom/build/nsXPComInit.cpp:484
12 	xul.dll 	ScopedXPCOMStartup::Initialize 	toolkit/xre/nsAppRunner.cpp:1181
13 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3942
14 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:4158
15 	firefox.exe 	do_main 	browser/app/nsBrowserApp.cpp:271
16 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:105
17 	firefox.exe 	__tmainCRTStartup 	crtexe.c:552
18 	kernel32.dll 	BaseProcessStart 		

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsTArray_Impl%3CnsAutoPtr%3Cmozilla%3A%3ACacheData%3E%2C+nsTArrayInfallibleAllocator%3E%3A%3AAppendElements%3Cmozilla%3A%3ACacheData*%3E%28mozilla%3A%3ACacheData*+const*%2C+unsigned+int%29

Comment 1

[Benjamin Smedberg]

I'd be a little surprised if this were an extension, but I guess weirder things have happened. 

This is a null-deref at http://hg.mozilla.org/releases/mozilla-beta/annotate/bc2783b0074d/modules/libpref/src/Preferences.cpp#l1589

gCacheData is supposed to have been initialized via

Preferences::GetUint
  ->GetInt
  ->InitStaticMembers
  do_GetService
  -> Preferences::GetInstanceForService

We can't really know what part of getservice/GetInstanceForService is failing. If an extension tried to override the prefservice by contractID and somehow failed, that could cause this. But note that at this point in startup there should be no addons loaded at all.

The conditions/functions which can fail and cause GetInstanceForService to fail are:
* NS_ENSURE_TRUE(!sShutdown)
* Preferences::Init
** PREF_Init
*** PL_DHashTableInit (allocation failure)
** pref_InitInitialObjects
*** pref_ReadPrefFromJar
*** jarReader->FindInit("defaults/pref/*.js$")
*** NS_GetSpecialDirectory(NS_GRE_DIR)
*** openPrefFile(greprefsFile)
*** NS_GetSpecialDirectory(NS_APP_PREF_DEFAULTS_50_DIR)
*** appJarReader->FindInit("defaults/preferences/*.js$")
*** pref_LoadPrefsInDirList(NS_APP_PREFS_DEFAULTS_DIR_LIST)
*** if (!observerService)

So there's actually a fair bit of surface area for this to fail, but mainly if omnijar is abnormal. Did this show up on Aurora or Nightly at all? My prime suspect would be something related to packaging or updates.

Comment 2

[Scoobidiver (away)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> Did this show up on Aurora or Nightly at all?
There are crashes in Beta (21.0b7, 22.0b1), Aurora (21.0a2, 22.0a2, 23.0a2) and Nightly (21.0a1, 22.0a1, 23.0a1) but no crashes in Release.

Comment 3

[Nicholas Nethercote [inactive]]

I'm pretty sure this is a dup of bug 1276488, which has added some diagnostics; it seems like corrupt omnijar is the cause.