386748 - Warning on Startup: NS_ENSURE_TRUE(compMgr) failed:

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Scott MacGregor]

When I start up thunderbird, I get a warning in the console about the component manager not being initialized. This is triggered by nsXREDirProvider::GetProfileDir attempt to get a directory for ProfD. 

 	CallGetService() Line 95	C++
 	nsGetServiceByContractIDWithError::operator()() Line 288	C++
 	nsCOMPtr<nsIProperties>::assign_from_gs_contractid_with_error() Line 1294	C++
 	nsCOMPtr<nsIProperties>::nsCOMPtr<nsIProperties>() Line 686	C++
 	NS_GetSpecialDirectory() Line 54	C++
 	nsXREDirProvider::GetProfileDir() Line 890	C++
 	nsXREDirProvider::GetFile() Line 319	C++
>	XRE_main() Line 2610	C++

Comment 2

[Justin Dolske [:Dolske]]

This has been happening with Firefox too. It's unfortunate that we start up  with a warning as the first line out output. :(

With a NS_BREAK() here, I get:

...
#4  0x0039fe5f in NS_DebugBreak_P
#5  0x003150a6 in CallGetService (aContractID=0x135fd0 "@mozilla.org/file/directory_service;1", aIID=@0x14b7b4, aResult=0xbfffe82c) at nsComponentManagerUtils.cpp:91
#6  0x00315666 in nsGetServiceByContractIDWithError::operator() (this=0xbfffe8a8, aIID=@0x14b7b4, aInstancePtr=0xbfffe82c) at nsComponentManagerUtils.cpp:291
#7  0x000f3bfa in nsCOMPtr<nsIProperties>::assign_from_gs_contractid_with_error (this=0xbfffe8a0, gs=@0xbfffe8a8, aIID=@0x14b7b4) at nsCOMPtr.h:1325
#8  0x000f3c54 in nsCOMPtr<nsIProperties>::nsCOMPtr (this=0xbfffe8a0, gs=@0xbfffe8a8) at nsCOMPtr.h:685
#9  0x000f3c72 in nsCOMPtr<nsIProperties>::nsCOMPtr (this=0xbfffe8a0, gs=@0xbfffe8a8) at nsCOMPtr.h:685
#10 0x000f3caf in NS_GetSpecialDirectory (specialDirName=0x137491 "ProfD", result=0xbfffebac) at nsDirectoryServiceUtils.h:53
#11 0x000f95d3 in nsXREDirProvider::GetProfileDir (this=0xbfffef34, aResult=0xbfffebac) at /Users/dolske/ff/trunk1/mozilla/toolkit/xre/nsXREDirProvider.cpp:974
#12 0x000fb54f in nsXREDirProvider::GetFile (this=0xbfffef34, aProperty=0x136e24 "UpdRootD", aPersistent=0xbffff010, aFile=0xbffff014) at /Users/dolske/ff/trunk1/mozilla/toolkit/xre/nsXREDirProvider.cpp:322
#13 0x000eecc3 in XRE_main (argc=1, argv=0xbffff2e0, aAppData=0x60eb80) at /Users/dolske/ff/trunk1/mozilla/toolkit/xre/nsAppRunner.cpp:2914
#14 0x000026d3 in main (argc=1, argv=0xbffff2e0) at /Users/dolske/ff/trunk1/mozilla/browser/app/nsBrowserApp.cpp:158

The error is triggered from frame 10 (as Scott noted), by trying to get ProfD. We don't even have one yet (selecting one is the very next step in nsAppRunner.cpp).

The real issue starts all the way at the beginning, in XRE_main(), where the MOZ_UPDATER block processes updates... It's looking for "UpdRootD" (aka XRE_UPDATE_ROOT_DIR), but in nsXREDirProvider::GetFile() this is #ifdef'd out for non-Windows platforms. Because of the way GetFile() is implemented, if the first giant section of if-else-else-else fails, it tried to grab ProfD and look inside it for other things.

This is a little silly in this case (and maybe others?) because looking in the profile dir isn't going to help.

Comment 3

[Justin Dolske [:Dolske]]

Attachment: Patch for review, v.1

Fixes problem by returning the error early. [The caller was getting this error anyway, and falls back to getting an update dir a different way]

Comment 4

[Justin Dolske [:Dolske]]

Checking in toolkit/xre/nsXREDirProvider.cpp;
/cvsroot/mozilla/toolkit/xre/nsXREDirProvider.cpp,v  <--  nsXREDirProvider.cpp
new revision: 1.66; previous revision: 1.65
done