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

VERIFIED FIXED in mozilla1.0.1

Status

()

--
critical
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: timeless, Assigned: timeless)

Tracking

({assertion, crash, topcrash+})

Trunk
mozilla1.0.1
assertion, crash, topcrash+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Assignee)

Description

17 years ago
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

17 years ago
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.
timeless, why in the world are you assigning this to me and not the default
necko owner?
Assignee: bryner → new-network-bugs
(Assignee)

Comment 3

17 years ago
*** Bug 107820 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

17 years ago
Blocks: 107391
(Assignee)

Comment 4

17 years ago
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...
Assignee: new-network-bugs → timeless
Severity: minor → critical
Keywords: assertion, crash
Summary: nsIOService::~nsIOService => nsIOService::SetOffline Getting service @mozilla.org/observer-service;1 on shutdown. → nsIOService::~nsIOService => nsIOService::SetOffline Getting service @mozilla.org/observer-service;1 on shutdown. [@nsThreadPool::Shutdown]
(Assignee)

Comment 5

17 years ago
Created attachment 84938 [details] [diff] [review]
draft [nsCRT whackage is due to another cleanup, i trimmed the easy parts]

Comment 6

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

sr=darin
Attachment #84938 - Flags: superreview+

Comment 7

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

r=dougt
Attachment #84938 - Flags: review+
(Assignee)

Comment 8

17 years ago
checked in
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 9

17 years ago
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?
Keywords: testcase, topcrash+
Summary: nsIOService::~nsIOService => nsIOService::SetOffline Getting service @mozilla.org/observer-service;1 on shutdown. [@nsThreadPool::Shutdown] → nsIOService::~nsIOService => nsIOService::SetOffline Getting service @mozilla.org/observer-service;1 on shutdown. - M100 N70PR1 [@ nsThreadPool::Shutdown]
(Assignee)

Updated

17 years ago
Keywords: mozilla1.0.1
Target Milestone: --- → mozilla1.0.1

Comment 10

17 years ago
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?
Keywords: nsbeta1

Comment 11

17 years ago
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+

Updated

17 years ago
Attachment #84938 - Flags: approval+
(Assignee)

Updated

17 years ago
Keywords: mozilla1.0.1+, nsbeta1 → fixed1.0.1

Comment 12

17 years ago
Timeless: how would I verify this?

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

Comment 13

17 years ago
Removing testcase keyword to avoid conflict. 
Keywords: testcase

Comment 14

17 years ago
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

17 years ago
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

17 years ago
Here are the IDs for the talkback reports:

9760144
9740763 
9674436 
9603842 

Timeless asked me to post for reference.

Comment 17

17 years ago
Jay: do you think we can mark this VERIFIED1.0.1?
Keywords: qawanted → verifyme

Comment 18

17 years ago
VERIFIED(trunk) per #14.
Status: RESOLVED → VERIFIED

Comment 19

16 years ago
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

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

Comment 21

16 years ago
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.

Updated

16 years ago
Keywords: fixed1.0.1 → verified1.0.1

Updated

10 years ago
Keywords: verifyme
Crash Signature: [@ nsThreadPool::Shutdown]
You need to log in before you can comment on or make changes to this bug.