485810 - crash nsComponentManagerImpl::GetServiceByContractID via nsImapMailFolder::NormalEndHeaderParseStream, mostly startup

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Wayne Mery (:wsmwk)]

3.0b3 topcrash
first appears with 2009031700 build. 
so apparent regression

bp-93c1d10d-98d3-4927-9d4c-a8c5e2090325
0	xpcom_core.dll	nsComponentManagerImpl::GetServiceByContractID	xpcom/components/nsComponentManager.cpp:2177
1	xpcom_core.dll	CallGetService	objdir-tb/mozilla/xpcom/build/nsComponentManagerUtils.cpp:94
2	xpcom_core.dll	nsGetServiceByContractID::operator	objdir-tb/mozilla/xpcom/build/nsComponentManagerUtils.cpp:278
3	xpcom_core.dll	nsCOMPtr_base::assign_from_gs_contractid	objdir-tb/mozilla/xpcom/build/nsCOMPtr.cpp:132
4	thunderbird.exe	nsCOMPtr<nsIMsgFolderNotificationService>::nsCOMPtr<nsIMsgFolderNotificationService>	objdir-tb/mozilla/dist/include/xpcom/nsCOMPtr.h:604
5	thunderbird.exe	nsImapMailFolder::NormalEndHeaderParseStream	mailnews/imap/src/nsImapMailFolder.cpp:2940
6	thunderbird.exe	nsImapMailFolder::ParseMsgHdrs	mailnews/imap/src/nsImapMailFolder.cpp:2774
7	xpcom_core.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
8	xpcom_core.dll	nsEventQueue::GetEvent	xpcom/threads/nsEventQueue.cpp:100
9	xpcom_core.dll	nsProxyObjectCallInfo::Run	xpcom/proxy/src/nsProxyEvent.cpp:181
10	xpcom_core.dll	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:510

Comment 1

[David :Bienvenu]

if we're crashing in the component manager, it's not an imap bug. It's either a component manager bug, or a build issue. Or it could be that we're shutting down, and the component manager is in a bad state.

Comment 2

[Wayne Mery (:wsmwk)]

so ...
a) xref TB2 Bug 350744 - crash when I start Thunderbird after a fresh install 
b) TB crashes start with 3.0b3pre build ~20090317041254 (confirming comment 1)
c) no TB 3.0b3pre crashes are during startup - all are after significant up time - none mention shutdown (ref comment 1)
d) Firefox - most (but not all) 3.1b3 crashes are during startup after 0-2 sec
   eg bp-4fd0ef73-1838-4d8a-af42-a890d2090414 (like bug 350744)
e) no crashes for FF or TB 1.9.2 based builds - yet

TB3 examples: bp-339a855a-fd82-4471-99dc-0a4112090413 and bp-93c1d10d-98d3-4927-9d4c-a8c5e2090325, which mentions "just reading emai (IMAP)l. Absolutely not doing anything unusual. "

I have no idea where I got the idea this is a TB3 topcrash, unless crash-stats lost some crashes.

Comment 3

[timeless]

so, each time i look, i see this block:
2190     if (entry->mServiceObject) {
2191         nsCOMPtr<nsISupports> serviceObject = entry->mServiceObject;
2192 
2193         // We need to not be holding the service manager's monitor while calling
2194         // QueryInterface, because it invokes user code which could try to re-enter
2195         // the service manager, or try to grab some other lock/monitor/condvar
2196         // and deadlock, e.g. bug 282743.
2197         mon.Exit();
2198         return serviceObject->QueryInterface(aIID, result);

it's entering the if block inside a monitor, addrefing mServiceObject as serviceObject, leaving the monitor, and then using it.

Unless the object in question isn't threadsafe (which is possible...)....

but bug 350744 is on the main thread and grabbing a perfectly reasonable object for the main thread:
95   nsCOMPtr<nsIObserverService> observerService = 
96            do_GetService("@mozilla.org/observer-service;1");

Comment 4

[Wayne Mery (:wsmwk)]

#183 for v3.0.4 so definitely not a topcrash.
90% are startup

there are a couple Mac crashes, but they don't look to be the same. feel free to disagree.
bp-807c3e06-c6a3-4dc9-85fc-36b992100326
bp-9502aa45-e7e2-4862-934f-686342100330

Comment 5

[John J. Barton]

Just FYI, if I have these lines in my startup observer, I crash FF 3.6.9pre with the call stack reported here. 
_xpcom_factory: 
    {
        createInstance: function(aOuter, aIID )
        {
            return gStartupObserverSingleton; 
        },
        lockFactory: function(){}, // no-op
    },

Comment 6

[Benjamin Smedberg]

jjb, do you have a complete example JS component which causes the crash? I presume it's an app-startup or profile-after-change observer, but I'd like to see exactly what it is.

Comment 7

[John J. Barton]

The code that works is:
http://code.google.com/p/fbug/source/browse/chromebug/branches/chromebug1.6/components/chromebug-startup-observer.js

(Also by svn http://code.google.com/p/fbug/source/checkout)

I believe that if you substitute the _xpcom_factory into the file it will crash, but I may have made a few more changes.  I can look in the local history on the machine I was using later today.

Comment 8

[timeless]

john: there's a second crasher in this code which needs its own bug. I suspect your case is that other bug.

Comment 9

[Sheila Mooney]

Yup, we still get this crash. 110 of these on 7.0.1 in the past week.

Comment 10

[Wayne Mery (:wsmwk)]

I'm not sure there's much happening today on the Firefox side that matches the original bug report. bp-d061ea1e-18ce-48a1-b578-bda2a2130113 for example is 
0	xul.dll	nsComponentManagerImpl::GetServiceByContractID	xpcom/components/nsComponentManager.cpp:1366
1	xul.dll	NS_CheckContentLoadPolicy	obj-firefox/dist/include/nsContentPolicyUtils.h:190
2	xul.dll	nsDocShell::InternalLoad	docshell/base/nsDocShell.cpp:8458
3	BthnetClock.dll	BthnetClock.dll@0x13017	
4	nspr4.dll	_MD_CURRENT_THREAD	nsprpub/pr/src/md/windows/w95thred.c:312
5	xul.dll	nsScriptSecurityManager::QueryInterface	caps/src/nsScriptSecurityManager.cpp:448 

but perhaps bp-d5619bfa-6baf-4896-baeb-5ad072130104 ?
0	xul.dll	nsComponentManagerImpl::GetServiceByContractID	xpcom/components/nsComponentManager.cpp:2199
1	xul.dll	CallGetService	obj-firefox/xpcom/build/nsComponentManagerUtils.cpp:94
2	xul.dll	nsXPCComponents_Interfaces::nsXPCComponents_Interfaces	js/src/xpconnect/src/xpccomponents.cpp:208
3	xul.dll	nsXPCComponents::GetInterfaces	js/src/xpconnect/src/xpccomponents.cpp:3906
4	xul.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
5	xul.dll	XPCWrappedNative::CallMethod	js/src/xpconnect/src/xpcwrappednative.cpp:2722 


On the other hand, there is a common theme in thunderbird crashes like
bp-933600dc-f3a4-42bd-a53c-e233e2130128
0		@0xd9c1ed24	
1	xul.dll	nsComponentManagerImpl::GetServiceByContractID	xpcom/components/nsComponentManager.cpp:1433
2	xul.dll	CallGetService	objdir-tb/mozilla/xpcom/build/nsComponentManagerUtils.cpp:62
3	xul.dll	nsGetServiceByContractID::operator	objdir-tb/mozilla/xpcom/build/nsComponentManagerUtils.cpp:246
4	xul.dll	nsCOMPtr_base::assign_from_gs_contractid	objdir-tb/mozilla/xpcom/build/nsCOMPtr.cpp:92
5	xul.dll	NS_RegisterMemoryReporter	xpcom/base/nsMemoryReporterManager.cpp:902
6	xul.dll	xptiInterfaceInfoManager::xptiInterfaceInfoManager	xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp:89

Comment 11

[Scoobidiver (away)]

The topcrash- keyword is not actively maintained and pollutes queries with topcrash.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'nsComponentManagerImpl::GetServiceByContractID':
 - nightly (version 51): 0 crashes from 2016-08-01.
 - aurora  (version 50): 0 crashes from 2016-08-01.
 - beta    (version 49): 19 crashes from 2016-08-02.
 - release (version 48): 15 crashes from 2016-07-25.
 - esr     (version 45): 9 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       0       0       0
 - aurora        0       0       0
 - beta          4       9       2
 - release       5       3       1
 - esr           0       1       0

Affected platform: Windows

Crash rank on the last 7 days:
           Browser     Content   Plugin
 - nightly
 - aurora
 - beta    #2316
 - release #2073
 - esr     #2500

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

I don't think we want to track this low volume crash. It seems likely to be a very low volume crash on beta/release for a long time, rather than something new that has cropped up in recent betas. I don't know that for sure, but that's how it looks. Calixte, n-i to you just to let you know an example that is unlikely to get any investigation...

Comment 14

[Wayne Mery (:wsmwk)]

For Thunderbird purposes this crash is virtually gone (and most certainly not a topcrash) unless the crash signature morphed (which it may have). So => WFM