394753 - crash during startup or shutdown [@ @0x7080149] [@ nsMsgAccountManager::`vector deleting destructor'(unsigned int)] // [@ arena_dalloc_small | arena_dalloc | free | nsMsgAccountManager::`vector deleting destructor'(unsigned int)]

Status: RESOLVED WORKSFORME

(Thunderbird :: Account Manager, defect)

Description

[Wayne Mery (:wsmwk)]

bp-6ef8666b-5a24-11dc-87f3-001a4bd43ed6
Thunderbird build 2007082704

crash  nsMsgAccountManager::`vector deleting destructor'(unsigned int)]
just after file > "restart thunderbird" (courtesy MR Tech Local Install I think).  But can't tell from sequence of events or crash report if it occurred during shutdown or start.  I'm guessing startup, given line 14 of stack is "BaseProcessStart"

Been using this build for several days and no unusual problems.  Two things I did during this session that are unusual activities for me:
1. some compacts on local folders, which I almost never do
2. I found a problem message that I can't do anything with - it displays in 3-pane, I can select text, and I can mark it(eg tag), but I can't do anything else: copy, view source, "save as".  Looking at menus now with *no* message selected, it's *exactly* the same as when I had this message *selected*.  (bug report later today)

0  	@0x7080149  	
1 	nsMsgAccountManager::`vector deleting destructor'(unsigned int) 	
2 	nsMsgAccountManager::Release() 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\mailnews\base\src\nsmsgaccountmanager.cpp:148
3 	nsRefPtr<nsThread>::assign_assuming_AddRef(nsThread*) 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\obj-tb-trunk\dist\include\xpcom\nscomptr.h:531
4 	nsCOMPtr_base::assign_with_AddRef(nsISupports*) 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\obj-tb-trunk\xpcom\build\nscomptr.cpp:89
5 	FreeServiceContractIDEntryEnumerate 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\xpcom\components\nscomponentmanager.cpp:1851
6 	PL_DHashTableEnumerate 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\obj-tb-trunk\xpcom\build\pldhash.c:724
7 	nsComponentManagerImpl::FreeServices() 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\xpcom\components\nscomponentmanager.cpp:1864
8 	NS_ShutdownXPCOM_P 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\xpcom\build\nsxpcominit.cpp:777
9 	ScopedXPCOMStartup::~ScopedXPCOMStartup() 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\toolkit\xre\nsapprunner.cpp:827
10 	XRE_main 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\toolkit\xre\nsapprunner.cpp:3111
11 	main 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\mail\app\nsmailapp.cpp:87
12 	WinMain 	d:\builds\tinderbox\tb-trunk\winnt_5.2_depend\mozilla\mail\app\nsmailapp.cpp:98
13 	__tmainCRTStartup 	f:\rtm\vctools\crt_bld\self_x86\crt\src\crtexe.c:578
14 	BaseProcessStart

Comment 1

[Wayne Mery (:wsmwk)]

philor, i've never seen this again. is there anything here worth keeping this open?

Comment 2

[Phil Ringnalda (:philor)]

I'm not the very last person on earth you should ask that question, but only because there are Stone Age tribes in the Amazon who've never seen a computer. Pretty sure you meant to cc bienvenu or Standard8, or bug-comment-ping timeless, instead.

Comment 3

[timeless]

not sure what caused it, but i can tell you that your destructor is broken. you need to cache the observer service, you can't try to getservice it from there. there's a comment, but it's fairly pointless.

since your object is registered as a service, this code will never do what it's trying to do. or if it does, bad things will happen. 

if there's a reference counting problem, this could explain it. you'd have an object that's dead, but still referenced which manages to convince the observer service to make it dead for the first time. when it finishes dying the second time, it'd crash.

Comment 4

[Wayne Mery (:wsmwk)]

not finding this anywhere on crash-stats, and i've never seen the crash again. But if it's like bug 484550, it will have a signature of 
 arena_dalloc_small | arena_dalloc | free | nsMsgAccountManager::`vector deleting destructor'(unsigned int)
so modding summary

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> not finding this anywhere on crash-stats

nsMsgAccountManager::`vector deleting destructor'(unsigned int) apparently still exists in tiny quantity on branch anyway, 2 crashes in 16 weeks.
v3.1.7 crashes
bp-197a7d56-a7a4-429b-a67c-b7f002110118
bp-2ca8a2b9-84a1-4b23-9088-6bbff2110225

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to timeless from comment #3)
> not sure what caused it, but i can tell you that your destructor is broken.
> you need to cache the observer service, you can't try to getservice it from
> there. there's a comment, but it's fairly pointless.
> 
> since your object is registered as a service, this code will never do what
> it's trying to do. or if it does, bad things will happen. 
> 
> if there's a reference counting problem, this could explain it. you'd have
> an object that's dead, but still referenced which manages to convince the
> observer service to make it dead for the first time. when it finishes dying
> the second time, it'd crash.

standard8, bienvenu, acelist do you see any reason to keep this bug:
1. given timeless's comment 
2. given I find no crashes on crash stats for a few random months

Comment 7

[David :Bienvenu]

(In reply to Wayne Mery (:wsmwk) from comment #6)
> (In reply to timeless from comment #3)
> > not sure what caused it, but i can tell you that your destructor is broken.
> > you need to cache the observer service, you can't try to getservice it from
> > there. there's a comment, but it's fairly pointless.
> > 
> > since your object is registered as a service, this code will never do what
> > it's trying to do. or if it does, bad things will happen. 
> > 
> > if there's a reference counting problem, this could explain it. you'd have
> > an object that's dead, but still referenced which manages to convince the
> > observer service to make it dead for the first time. when it finishes dying
> > the second time, it'd crash.
> 
> standard8, bienvenu, acelist do you see any reason to keep this bug:
> 1. given timeless's comment 
> 2. given I find no crashes on crash stats for a few random months

no, I'd mark it WFM or incomplete. I'm pretty sure it was a shutdown crash, fwiw.