XPCOM Asserts/warnings when closing mfcEmbed and mozilla




17 years ago
7 years ago


(Reporter: David Epstein, Unassigned)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




17 years ago
Reproduced in 10/27 debug mozilla nightly build.
1. Install latest mozilla build.
2. Launch mfcEmbed from /dist/WIN32_D.OBJ/bin
3. Quit the app.
Result: ASS ERTION: Component Manager being held past XPCOM shutdown: 'cnt==0',
file /mozilla/xpcom/build/nsXPComInit.cpp, line 526.
Note: Don't see the assertion again. It's happening after first time launch.

2nd case:
1. Launch mozilla from /dist/WIN32_D.OBJ/bin
2. Quit the app.
Result: Get several repetitions of the same Warning message in the console:
"WARNING: Creating new service on shutdown. Denied. file
/mozilla/xpcom/components/nsComponentManager.cpp, line 1760.

stack trace for mfcEmbed assert:
NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x100f8eb4, const char * 0x100f8ea8, const char
* 0x100f8e74, int 526) line 290 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x100f8eb4, const char * 0x100f8ea8, const
char * 0x100f8e74, int 526) line 396 + 21 bytes
NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 526 + 31 bytes
NS_TermEmbedding() line 161 + 13 bytes
CMfcEmbedApp::ExitInstance() line 431
CWinThread::Run() line 488 + 11 bytes
CWinApp::Run() line 400
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
0x001340f0, int 10) line 49 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x001340f0,
int 10) line 30
WinMainCRTStartup() line 330 + 54 bytes

Comment 1

17 years ago
yup.  The problem is not in XPCOM.  When XPCOM is being destroyed, objects
destructors are trying to call getService on the nsIServiceManager.  We are
denying them.  They should register shutdown listeners instead.

We need to fix these at some point.  

David, are you up for filing bugs against the objects that cause these
assertions and making the blockers to this one??

Comment 2

17 years ago
With Radha's help, this is what I found:
I had put breakpoint in nsComponentManager::GetServiceByContractID().
It hits the warning message in nsComponentManager: line 2075 after being called 
by nsPluginHostImpl::~nsPluginHostImpl(). It looks like this code in 
nsPluginHostImpl.cpp was already there and it was last touched by you on 10/22 
for bug 99163. It appears that your change was to modify a #define for 
contractId to the actual string.

However, nsComponentManager::GetServiceByContractID(), where the actual warning 
is sent out, was last added by you on V. 1.158 for bug 96457.  It looks like 
this was done, as part of merging servicemanager with componentManager. I'm not 
sure, if the cause of this problem is nsPluginHostImpl or nsComponentManager. 

Comment 3

17 years ago
no no no.  the warning were always present.  DP change a #define DEBUG_dp to a
#define DEBUG so that everyone would get these warning (which they should).

Don't look to deeping at the change logs.  the problem is more appearant than
that... People are calling getService as their service shutdown.  this is
unsupported and results are not defined.

Comment 4

17 years ago
Lookng further, using F5 to advance in the debugger, these modules also call 
do_GetService() in their destructors:

nsJSEnvironment.cpp::~nsJSContext() line 414 and 421 multiple times.

Hope this helps.

Comment 5

17 years ago
file seperate bugs against these callers.  Please cite the object whose
destructor is calling getService()


17 years ago
Depends on: 107485


17 years ago
Blocks: 107585


17 years ago
Depends on: 107820


17 years ago
Depends on: 107891


17 years ago
Depends on: 108046


17 years ago
Depends on: 108047


17 years ago
Depends on: 108052

Comment 6

17 years ago
I looked at a lot of these and most of them were destructors trying to get
themselves unregistered from the pref service, observer service etc...

This pattern seems right. If they cannot get service, they are sure that they
are not in those services callback lists.

So I think we should just remove the warning unless we are advocating another

Comment 7

17 years ago
*** Bug 108306 has been marked as a duplicate of this bug. ***


17 years ago
Target Milestone: --- → Future
*** Bug 112339 has been marked as a duplicate of this bug. ***

Comment 9

17 years ago
Doug, I *really* think we should switch this warning off.

Comment 10

17 years ago
okay.  check in a patch. :-)  As I remember, this was a DEBUG_dp #define to
begin with. :-) ;-)

Comment 11

17 years ago
Yeah! But look at the bright side - you are hero now!!!


16 years ago
Keywords: meta
OS: Windows NT → All
Hardware: PC → All


16 years ago
No longer depends on: 107820, 108047


16 years ago
Depends on: 134723, 134724, 134728


16 years ago
Depends on: 136274


16 years ago
Depends on: 133383
No longer depends on: 107891


15 years ago
QA Contact: scc → carosendahl
Assignee: dougt → nobody
QA Contact: carosendahl → xpcom
Mass marking all MFCEmbed bugs as wontfix, since bug 377410 removed it. If this bug was erroneously included (or say equally applies to winEmbed), please reopen & accept my apologies.

Filter bugspam on mfcEmbedwontfix.
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.