Closed Bug 277234 Opened 21 years ago Closed 21 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: 21 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: