Closed Bug 613835 Opened 9 years ago Closed 9 years ago

crash close to startup [@ nsCOMPtr_base::~nsCOMPtr_base() | nsTHashtable<nsBaseHashtableET<PrefCallback, nsAutoPtr<PrefCallback> > >::s_ClearEntry(PLDHashTable*, PLDHashEntryHdr*) ]


(Core :: Preferences: Backend, defect, critical)

Not set



Tracking Status
blocking2.0 --- betaN+


(Reporter: scoobidiver, Assigned: dwitte)



(Keywords: crash, regression, topcrash)

Crash Data

It is a new crash signature. Crashes first appeared in 4.0b8pre/20101115 build.
It is #16 top crasher in 4.0b8pre for the last 3 days.

Signature	nsCOMPtr_base::~nsCOMPtr_base() | nsTHashtable<nsBaseHashtableET<PrefCallback, nsAutoPtr<PrefCallback> > >::s_ClearEntry(PLDHashTable*, PLDHashEntryHdr*)
UUID	5f26f923-4fdc-4cb8-814d-2dac22101120
Time 	2010-11-20 21:18:28.766136
Uptime	0
Install Age	16225 seconds (4.5 hours) since version was first installed.
Product	Firefox
Version	4.0b8pre
Build ID	20101120044537
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Service Pack 2
CPU	x86
CPU Info	GenuineIntel family 15 model 4 stepping 9
Crash Address	0x6f72686b
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 06e1

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsCOMPtr_base::~nsCOMPtr_base 	obj-firefox/dist/include/nsAutoPtr.h:969
1 	xul.dll 	nsTHashtable<nsBaseHashtableET<PrefCallback,nsAutoPtr<PrefCallback> > >::s_ClearEntry 	obj-firefox/dist/include/nsTHashtable.h:397
2 	xul.dll 	PL_DHashTableRawRemove 	obj-firefox/xpcom/build/pldhash.c:723
3 	xul.dll 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.c:757
4 	xul.dll 	nsPrefBranch::Observe 	modules/libpref/src/nsPrefBranch.cpp:707
5 	xul.dll 	nsObserverList::NotifyObservers 	xpcom/ds/nsObserverList.cpp:130
6 	xul.dll 	nsObserverService::NotifyObservers 	xpcom/ds/nsObserverService.cpp:182
7 	xul.dll 	mozilla::ShutdownXPCOM 	xpcom/build/nsXPComInit.cpp:631
8 	xul.dll 	ScopedXPCOMStartup::~ScopedXPCOMStartup 	toolkit/xre/nsAppRunner.cpp:1117
9 	xul.dll 	XRE_main 	
10 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:128
11 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
12 	kernel32.dll 	BaseProcessStart 	

More reports at:|%20nsTHashtable%3CnsBaseHashtableET%3CPrefCallback%2C%20nsAutoPtr%3CPrefCallback%3E%20%3E%20%3E%3A%3As_ClearEntry%28PLDHashTable*%2C%20PLDHashEntryHdr*%29&version=Firefox%3A4.0b8pre
blocking2.0: --- → ?
looks like a startup crash with no useful urls to test.

Correlation to startup or time of session
17 total crashes for nsCOMPtr_base::.nsCOMPtr_base.....nsTHashtable.nsBaseHashtableET.PrefCallback on 20101119-crashdata.csv
16 startup crashes inside 30 sec.
17 startup crashes inside 3 min.

os breakdown
nsCOMPtr_base::.nsCOMPtr_base.....nsTHashtable.nsBaseHashtableET.PrefCallbackTotal 17
Win5.1  0.76
Win6.0  0.06
Win6.1  0.18
Assignee: nobody → dwitte
blocking2.0: ? → beta9+
move up to #11 top crash on trunk.  this is a new regression since b7.   we should try and understand it better before we ship b8.

Looks like reports are highly concentrated on two builds

reports  build ID
  55 20101119042412
  37 20101120044537

since we haven't seen it on builds later than 11/20 is it possible its been fixed?
Bug 614286 seems to have a really similar (identical?) stack, 64bit OS X when starting offline.
> since we haven't seen it on builds later than 11/20 is it possible its been
> fixed?
It is a moving crash signature. See:
nsRefPtr<nsPresContext>::~nsRefPtr<nsPresContext>() | nsTHashtable<nsBaseHashtableET<PrefCallback, nsAutoPtr<PrefCallback> > >::s_ClearEntry(PLDHashTable*, PLDHashEntryHdr*) 
As the new signature is as long as the first one, it can't be added to the bug title.
Component: XPCOM → Preferences: Backend
QA Contact: xpcom → preferences-backend
Duplicate of this bug: 614761
Duplicate of this bug: 615293
Happens on Mac as well, changing to all.
OS: Windows XP → All
Hardware: x86 → All
This is #6 on the trunk these days. Adding topcrash keyword.
Keywords: topcrash
(In reply to comment #3)
> Bug 614286 seems to have a really similar (identical?) stack, 64bit OS X when
> starting offline.

looks like patches landed for that bug yesterday.

crashes for this signature have been seen in builds as late as 2010 12 01 03 0318

time to watch this more closely to see if it goes away with the fix from Bug 614286
For all sigs containing 'nsTHashtable<nsBaseHashtableET<PrefCallback', we have:

11/19 - 11/26: 472
11/26 - 12/3:  542
12/3 - 12/10:  109

So the frequency has gone down by a significant amount, but it's not gone. Still needs investigating...
Actually, the last build these were seen in was 20101201030318, so it does indeed look like bug 614286 took care of this.
Closed: 9 years ago
Resolution: --- → FIXED
As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)
blocking2.0: beta9+ → betaN+
Crash Signature: [@ nsCOMPtr_base::~nsCOMPtr_base() | nsTHashtable<nsBaseHashtableET<PrefCallback, nsAutoPtr<PrefCallback> > >::s_ClearEntry(PLDHashTable*, PLDHashEntryHdr*) ]
You need to log in before you can comment on or make changes to this bug.