Closed
Bug 273819
Opened 20 years ago
Closed 20 years ago
ASSERTION: Native event queues should only be used on the main thread
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
mozilla1.8beta1
People
(Reporter: darin.moz, Assigned: darin.moz)
Details
(Keywords: crash)
Attachments
(1 file)
|
3.22 KB,
patch
|
danm.moz
:
review+
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
NTDLL! 77f75a58()
nsDebugImpl::Assertion(nsDebugImpl * const 0x00f8d310, const char * 0x00373900,
const char * 0x003738e4, const char * 0x003738a8, int 0x000000e4) line 290
nsDebug::Assertion(const char * 0x00373900, const char * 0x003738e4, const char
* 0x003738a8, int 0x000000e4) line 109
nsEventQueueImpl::NotifyObservers(const char * 0x0033bdec
gDestroyedNotification) line 228 + 34 bytes
nsEventQueueImpl::~nsEventQueueImpl() line 139
nsEventQueueImpl::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsEventQueueImpl::Release(nsEventQueueImpl * const 0x0315f318) line 195 + 142 bytes
nsCOMPtr<nsIEventQueue>::~nsCOMPtr<nsIEventQueue>() line 584
nsTimerImpl::PostTimerEvent() line 508 + 8 bytes
TimerThread::Run(TimerThread * const 0x003e82b0) line 287
nsThread::Main(void * 0x00f90538) line 118 + 26 bytes
_PR_NativeRunThread(void * 0x00f90638) line 436 + 13 bytes
pr_root(void * 0x00f90638) line 116 + 13 bytes
_threadstartex(void * 0x00f908c0) line 212 + 13 bytes
KERNEL32! 77e7d33b()
It would appear that the last reference to this particular native event queue is
being held by the timer thread. As a result, we destroy the native event queue
on the timer thread, and in doing so, we call into the appshell code on the
timer thread. This explains why checking IsMainThread was "wrong" previously.
What we should do I think is move the final call to NotifyObservers from the
destructor into CheckForDeactivation since that function will only ever be
called on the main thread.
This bug is a potential crash on all platforms.
| Assignee | ||
Updated•20 years ago
|
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
| Assignee | ||
Comment 1•20 years ago
|
||
It actually isn't possible to tear down the event queue in CheckForDeactivation
since there may still be pending events that need to be processed. We could
possibly tear down the native notify logic at that point, but that feels risky.
The solution is perhaps to tear down the event queue once we process the last
pending event on a deactivated event queue. Then we should be fine provided
ProcessPendingEvents is always called ;-)
| Assignee | ||
Comment 2•20 years ago
|
||
Possible patch. This seems to do the trick.
Attachment #168681 -
Flags: review?(danm.moz)
Attachment #168681 -
Flags: review?(danm.moz) → review+
| Assignee | ||
Updated•20 years ago
|
Attachment #168681 -
Flags: superreview?(bienvenu)
Updated•20 years ago
|
Attachment #168681 -
Flags: superreview?(bienvenu) → superreview+
| Assignee | ||
Comment 3•20 years ago
|
||
fixed-on-trunk
begin prayer to the talkback goddess.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•