EventQueue destruction should not happen along with servicemanager destruction

RESOLVED INVALID

Status

()

P3
normal
RESOLVED INVALID
19 years ago
13 years ago

People

(Reporter: dp, Unassigned)

Tracking

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Eventqueue destruction is happening off servicemanager destruction. The problem
with this is that the GetService() from NotifyObserver() is going to fail as
servicemanager will deny any GetService() request on shutdown.

The best would be to do the eventqueue destruction on
NS_XPCOM_SHUTDOWN_OBSERVER_ID observer.


#2  0x4016b9b0 in nsServiceManager::GetService (aProgID=0x401a5980
"component://netscape/observer-service", aIID=@0x401ab628, result=0xbffff464,
shutdownListener=0x0) at nsServiceManager.cpp:547
#3  0x4016a7f7 in nsGetServiceByProgID::operator() (this=0xbffff4bc,
aIID=@0x401ab628, aInstancePtr=0xbffff464) at nsServiceManager.cpp:59
#4  0x4018f2ec in nsCOMPtr<nsIObserverService>::assign_from_helper
(this=0xbffff4cc, helper=@0xbffff4bc, aIID=@0x401ab628) at
../../dist/include/nsCOMPtr.h:768
#5  0x4018f3b1 in nsCOMPtr<nsIObserverService>::nsCOMPtr (this=0xbffff4cc,
helper=@0xbffff4bc) at ../../dist/include/nsCOMPtr.h:496
#6  0x4016d68b in nsEventQueueImpl::NotifyObservers (this=0x8896e60,
aTopic=0x401a584f "nsIEventQueueDestroyed") at nsEventQueue.cpp:105
#7  0x4016d2e3 in nsEventQueueImpl::~nsEventQueueImpl (this=0x8896e60,
__in_chrg=3) at nsEventQueue.cpp:62
(More stack frames follow...)
(gdb)

Updated

19 years ago
Whiteboard: needs danm triage

Comment 1

19 years ago
danm, please triage.
(Reporter)

Updated

19 years ago
Summary: EventQueue destruction should happen along with servicemanager destruction → EventQueue destruction should not happen along with servicemanager destruction
(Reporter)

Comment 2

19 years ago
This aint M12. More like beta.

Updated

19 years ago
Status: NEW → ASSIGNED
Whiteboard: needs danm triage
Target Milestone: M16

Comment 3

19 years ago
dp and I have discussed this. Its shutdown misbehaviour is causing some furrowed brows
in the service manager, but no noticeable damage is done. It wants to be fixed, but there's
no emergency.

Comment 4

19 years ago
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17

Comment 5

19 years ago
moving to m18
Target Milestone: M17 → M18

Comment 6

19 years ago
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21

Updated

19 years ago
Target Milestone: M21 → Future

Comment 7

19 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer

Comment 8

18 years ago
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok

Comment 10

18 years ago
QA contact updated
QA Contact: gerardok → madhur

Updated

17 years ago
QA Contact: madhur → rakeshmishra

Updated

16 years ago
QA Contact: rakeshmishra → trix

Updated

14 years ago
Assignee: danm.moz → nobody
Status: ASSIGNED → NEW

Comment 11

13 years ago
I believe we can close this bug, now that bug 326273 is fixed.  Marking INVALID since the core problem no longer applies in the threadmanager world.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.