Closed Bug 277234 Opened 20 years ago Closed 20 years ago

[FIXr]crash [@ nsSynthMouseMoveEvent::HandleEvent]

Categories

(Core :: Web Painting, defect, P1)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
mozilla1.8alpha6

People

(Reporter: darin.moz, Assigned: bzbarsky)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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?
I have only seen the crash once, but I'll definitely help test out whatever
patch you come up with.
Attached patch Proposed patchSplinter Review
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: 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 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
Closed: 20 years ago
Resolution: --- → FIXED
Severity: normal → critical
Summary: [FIXr]crash @nsSynthMouseMoveEvent::HandleEvent() → [FIXr]crash [@ nsSynthMouseMoveEvent::HandleEvent]
Crash Signature: [@ nsSynthMouseMoveEvent::HandleEvent]
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: