134724 - nsIOService::~nsIOService => nsIOService::SetOffline Getting service @mozilla.org/observer-service;1 on shutdown. - M100 N70PR1 [@ nsThreadPool::Shutdown]

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[timeless]

Getting service on shutdown. Denied.
  ContractID: @mozilla.org/observer-service;1
         IID: {d07f5192-e3d1-11d2-8acd-00105a1b8860}
###!!! ASSERTION: stop for contractid: '0', file /home/timeless/mozilla/xpcom/components/nsComponentManager.cpp, line 2158
###!!! Break: at file /home/timeless/mozilla/xpcom/components/nsComponentManager.cpp, line 2158

#2  0x2831cba9 in nsDebug::Assertion (aStr=0x2836d288 "stop for contractid", 
aExpr=0x2836d108 "0", aFile=0x2836c6c0 "/home/timeless/mozilla/xpcom/components/nsComponentManager.cpp",
    aLine=2158) at /home/timeless/mozilla/xpcom/glue/nsDebug.cpp:291
#3  0x282c3701 in nsComponentManagerImpl::GetServiceByContractID 
(this=0x80c4000, aContractID=0x28ad3380 "@mozilla.org/observer-service;1", 
aIID=@0x806b8bc, result=0xbfbff368)
    at /home/timeless/mozilla/xpcom/components/nsComponentManager.cpp:2158
#4  0x2831f73e in nsGetServiceByContractID::operator() (this=0xbfbff4e8, 
aIID=@0x806b8bc, aInstancePtr=0xbfbff368)
    at /home/timeless/mozilla/xpcom/glue/nsComponentManagerUtils.cpp:123
#5  0x08063053 in nsCOMPtr<nsIObserverService>::assign_from_helper 
(this=0xbfbff4f8, helper=@0xbfbff4e8, aIID=@0x806b8bc) at 
../../dist/include/xpcom/nsCOMPtr.h:922
#6  0x08066753 in nsCOMPtr<nsIObserverService>::nsCOMPtr (this=0xbfbff4f8, 
helper=@0xbfbff4e8) at ../../dist/include/xpcom/nsCOMPtr.h:553
#7  0x28a0bd12 in nsIOService::SetOffline (this=0x8128200, offline=1) at 
/home/timeless/mozilla/netwerk/base/src/nsIOService.cpp:840
#8  0x28a08b87 in nsIOService::~nsIOService (this=0x8128200, __in_chrg=3) at 
/home/timeless/mozilla/netwerk/base/src/nsIOService.cpp:250
#9  0x28a0906f in nsIOService::Release (this=0x8128200) at 
/home/timeless/mozilla/netwerk/base/src/nsIOService.cpp:296

Yes I know, shame on me for using NS_ASSERTION(0, ...)

Comment 1

[Alec Flett]

I have another bug about general service-warnings on exit, I had a patch that
fixed this but turned linux orange, and I got backed out. This was a while back,
but basically what you need to do is make nsIOService an observer on the
xpcom-shutdown topic in the observer service, if its not already, and call
SetOffline() in the observe method instead.

Comment 2

[Brian Ryner (not reading)]

timeless, why in the world are you assigning this to me and not the default
necko owner?

Comment 3

[timeless]

*** Bug 107820 has been marked as a duplicate of this bug. ***

Comment 4

[timeless]

fwiw zurk triggered this talkback:
Stack Signature  nsThreadPool::Shutdown 00731bdd
Product ID Gecko1.0
Build ID 2002051008
Trigger Time 2002-05-22 11:29:35
Platform Win32
Operating System Windows 98 4.10 build 67766446
Module XPCOM.DLL
URL visited startup
User Comments tried to startup and it crashed.
Trigger Reason Access violation
Source File Name d:\builds\seamonkey\mozilla\xpcom\threads\nsThread.cpp
Trigger Line No. 741
Stack Trace
nsThreadPool::Shutdown 
[d:\builds\seamonkey\mozilla\xpcom\threads\nsThread.cpp, line 741]
nsFileTransportService::Shutdown 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsFileTransportService.cpp, 
line 217]
nsIOService::~nsIOService 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsIOService.cpp, line 253]
nsIOService::`scalar deleting destructor'
nsHttpHandler::Release 
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpHandler.cpp, 
line 1787]
nsCOMPtr_base::assign_with_AddRef 
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 74]
PL_DHashTableEnumerate [d:\builds\seamonkey\mozilla\xpcom\ds\pldhash.c, 
line 601]
NECKO.DLL + 0x43654 (0x609a3654)
nsIOService::AddRef 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsIOService.cpp, line 299]
0x85107d8b

alright. enough's enough, time for me to try to fix this...

Comment 5

[timeless]

Attachment: draft [nsCRT whackage is due to another cleanup, i trimmed the easy parts]

Comment 6

[Darin Fisher]

Comment on attachment 84938 [details] [diff] [review]
draft [nsCRT whackage is due to another cleanup, i trimmed the easy parts]

sr=darin

Comment 7

[Doug Turner (:dougt)]

Comment on attachment 84938 [details] [diff] [review]
draft [nsCRT whackage is due to another cleanup, i trimmed the easy parts]

r=dougt

Comment 8

[timeless]

checked in

Comment 9

[Jay Patel [:jay]]

Adding topcrash+, testcase keywords...and M100 N70PR1 to summary for future
reference.  This has been a topcrahser for Mozilla 1.0 and Netscape 7.0PR1.  

Was this fix checked into the Gecko1.0 Branch and the MozillaTrunk?

Comment 10

[Jay Patel [:jay]]

I just found out that this was only checked in on the MozillaTrunk...NOT on the
Gecko1.0 Branch.  Nominating for nsbeta1...probably too late for RTM, but if we
can get this in that would be great!  

It's been a topcrasher (within the top 20) for the last three Mozilla 1.0 RCs,
as well as Mozilla 1.0 and Netscape 7.0 PR1.  If timeless's fix is safe, can we
get it onto the branch?

Comment 11

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 12

[benc]

Timeless: how would I verify this?

Jpatel: how is this a testcase? can you provide steps?

Comment 13

[Shiva Thirumazhusai]

Removing testcase keyword to avoid conflict. 

Comment 14

[Jay Patel [:jay]]

Ben: We don't have any testcase to use in verifying this crash (sorry for the
confusion).  The best way to verify it is to look at current Talkback data.  

Before I wrote my comment #10, I just verified that the crash was no longer
showing up in Trunk Talkback data after the checkin on the Trunk.  You can
either do a query for "nsThreadPool::Shutdown" from the Talkback reports page
(http://climate.mcom.com) or look at the topcrash reports for recent Branch
(M1BR) builds .

Comment 15

[lchiang]

I looked at the topcrash reports for M1BR builds.
There were 4 crashes for 8-15 with this stack trace: nsThreadPool::Shutdown
0 reported since then.

However, this bug report is marked fixed back in June 2002.  I'm wondering if
the crash is still there, but we've made it less easy to get the crash.

I don't want to mark this verified on branch yet.  Jay - can you confirm my
findings?

Comment 16

[lchiang]

Here are the IDs for the talkback reports:

9760144
9740763 
9674436 
9603842 

Timeless asked me to post for reference.

Comment 17

[benc]

Jay: do you think we can mark this VERIFIED1.0.1?

Comment 18

[benc]

VERIFIED(trunk) per #14.

Comment 19

[Jay Patel [:jay]]

Looking at the latest incidents from the Gecko 1.0 Branch, the stack is different:
Incident ID 9760144
Stack Signature nsThreadPool::Shutdown be664a08
Email Address 
Product ID Gecko1.0
Build ID 2002081508
Trigger Time 2002-08-23 19:59:56
Platform Win32
Operating System Windows NT 5.1 build 2600
Module xpcom.dll
URL visited Mozilla Home Page
User Comments
Trigger Reason Access violation
Source File Name d:\builds\seamonkey\mozilla\xpcom\threads\nsThread.cpp
Trigger Line No. 745
Stack Trace
nsThreadPool::Shutdown [d:\builds\seamonkey\mozilla\xpcom\threads\nsThread.cpp,
line 745]
nsFileTransportService::Shutdown
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsFileTransportService.cpp, line 226]
nsIOService::Observe
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsIOService.cpp, line 1045]
nsObserverService::NotifyObservers
[d:\builds\seamonkey\mozilla\xpcom\ds\nsObserverService.cpp, line 213]
NS_ShutdownXPCOM [d:\builds\seamonkey\mozilla\xpcom\build\nsXPComInit.cpp, line 544]
main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1847]
WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1857]
WinMainCRTStartup()
kernel32.dll + 0x1eb69 (0x77e7eb69) 

So those might be a different crash (or a rare case of this crash).

Based on the Talkback data for the Trunk, the number of these crashes went from
A LOT to very little or none after the checkin...so it is safe to say that this
was a good fix there.  On the Branch however, we have not had a lot of Talkback
data since Mozilla 1.0 (and this checkin went in after that release) so it is
more difficult to verify.

If we can verify that the stack I just posted is different than the crash
originally reported, it would be safe to say this is verified1.0.1.

Comment 20

[benc]

jpatel: who needs to look at this to branch verify? I am trying to mop up my
work for the branch ASAP.

Comment 21

[Jay Patel [:jay]]

From looking at the Gecko 1.0 Branch and recent Mozilla 1.0.1 data...it should
be safe to verify this as verified1.0.1.  

There are still crashes happening under the same stack signature, but as I noted
in my last comment, the stack is different.  That crash is now being looked at
in bug 166371.  

I think this bug is done.