[FIXr]crash [@ nsSynthMouseMoveEvent::HandleEvent]

RESOLVED FIXED in mozilla1.8alpha6

Status

()

Core
Layout: View Rendering
P1
critical
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Darin Fisher, Assigned: bz)

Tracking

({crash})

Trunk
mozilla1.8alpha6
x86
Windows XP
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
While running the Tdhtml test in a debug build, I hit a crash inside the View
Manager.  Here's the stack:

nsCOMPtr<nsIEventQueue>::assign_assuming_AddRef(nsIEventQueue * 0x00000000) line
568 + 3 bytes
nsCOMPtr<nsIEventQueue>::assign_with_AddRef(nsISupports * 0x00000000) line 1225
nsCOMPtr<nsIEventQueue>::operator=(nsIEventQueue * 0x00000000) line 714
nsViewManager::ProcessSynthMouseMoveEvent(int 0) line 4253
nsSynthMouseMoveEvent::HandleEvent() line 4199
HandlePLEvent(PLEvent * 0x0348f6dc) line 367
PL_HandleEvent(PLEvent * 0x0348f6dc) line 698 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ef5e68) line 633 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00080488, unsigned int 49461, unsigned int 0,
long 15687272) line 1472 + 9 bytes
USER32! 77d43a50()
USER32! 77d43b1f()
USER32! 77d43d79()
USER32! 77d43ddf()
nsAppStartup::Run(nsAppStartup * const 0x00f02da8) line 147
xre_main(int 3, char * * 0x003e77d8, const nsXREAppData * 0x0041e01c kAppData)
line 2140 + 35 bytes
main(int 3, char * * 0x003e77d8) line 60 + 18 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()

It looks like the value of mSynthMouseMoveEventQueue is 0xdddddddd, and we crash
trying to call nsISupports::Release on it.
Hmmm... We should be calling RevokeEvents() on all viewmanagers, but even so I'm
not sure why this is crashing.  Deleted viewmanagers are removed from the global
viewmanager array, and the code in HandlePLEvent() should be bailing out if the
target viewmanager is already dead...

Perhaps the mouse event is killing the viewmanager, somehow?  That would be
consistent with where we crash.

Patch coming up that ought to fix this.  I can't seem to reproduce, so could you
test this one, darin?
(Reporter)

Comment 2

14 years ago
I have only seen the crash once, but I'll definitely help test out whatever
patch you come up with.
Created attachment 170474 [details] [diff] [review]
Proposed patch
Assignee: roc → bzbarsky
Status: NEW → ASSIGNED
Attachment #170474 - Flags: superreview?(darin)
Attachment #170474 - Flags: review?(dbaron)
Priority: -- → P1
Summary: crash @nsSynthMouseMoveEvent::HandleEvent() → [FIX]crash @nsSynthMouseMoveEvent::HandleEvent()
Target Milestone: --- → mozilla1.8alpha6
Attachment #170474 - Flags: review?(dbaron) → review+
(Reporter)

Updated

14 years ago
Attachment #170474 - Flags: superreview?(darin) → superreview+
Summary: [FIX]crash @nsSynthMouseMoveEvent::HandleEvent() → [FIXr]crash @nsSynthMouseMoveEvent::HandleEvent()
Comment on attachment 170474 [details] [diff] [review]
Proposed patch

Could this crash fix be approved for 1.8a6?  It should be about as safe as
crash fixes get....
Attachment #170474 - Flags: approval1.8a6?

Comment 5

14 years ago
Comment on attachment 170474 [details] [diff] [review]
Proposed patch

a=asa (on behalf of drivers) for checkin to 1.8a6.
Attachment #170474 - Flags: approval1.8a6? → approval1.8a6+
Fixed for 1.8a6.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

14 years ago
Severity: normal → critical

Updated

14 years ago
Summary: [FIXr]crash @nsSynthMouseMoveEvent::HandleEvent() → [FIXr]crash [@ nsSynthMouseMoveEvent::HandleEvent]
Crash Signature: [@ nsSynthMouseMoveEvent::HandleEvent]
You need to log in before you can comment on or make changes to this bug.