Closed Bug 468753 Opened 12 years ago Closed 12 years ago

Startup crash in nsViewManager::ProcessSynthMouseMoveEvent


(Core :: Web Painting, defect)

Not set





(Reporter: roc, Assigned: roc)



(Keywords: fixed1.9.1, regression)


(1 file)


#0  0x021e21b2 in nsViewManager::ProcessSynthMouseMoveEvent (this=0x91f3160, aFromScroll=0) at /Users/roc/mozilla-trunk/view/src/nsViewManager.cpp:2418
#1  0x021e4a38 in nsSynthMouseMoveEvent::Run (this=0xca175d0) at /Users/roc/mozilla-trunk/view/src/nsViewManager.cpp:2281
#2  0x0049f344 in nsThread::ProcessNextEvent (this=0xa16240, mayWait=0, result=0xbfffd724) at /Users/roc/mozilla-trunk/xpcom/threads/nsThread.cpp:510
#3  0x0042927e in NS_ProcessPendingEvents_P (thread=0xa16240, timeout=20) at nsThreadUtils.cpp:180
#4  0x048f6c6d in nsBaseAppShell::NativeEventCallback (this=0x50133a0) at /Users/roc/mozilla-trunk/widget/src/xpwidgets/nsBaseAppShell.cpp:121
#5  0x048ae930 in nsAppShell::ProcessGeckoEvents (aInfo=0x50133a0) at /Users/roc/mozilla-trunk/widget/src/cocoa/

I think Josh has seen this.

The crash is at
  pointVM->GetViewObserver()->DispatchSynthMouseMove(&event, !aFromScroll);
GetViewObserver has returned null. I think we just need to null-check it. Since we're running off an event it is definitely possible that PresShell::Destroy has been called which has called SetViewObserver(nsnull) on the view manager (assuming something is keeping a reference to the view manager which has prevented mSynthMouseMoveEvent.Revoke() from running in the destructor).
This should do it.
Attachment #352253 - Flags: superreview?(dbaron)
Attachment #352253 - Flags: review?(dbaron)
Flags: blocking1.9.1?
Whiteboard: [needs review]
Comment on attachment 352253 [details] [diff] [review]
[Checkin: Comment 5 & 8]

r+sr=dbaron.  Thanks for cleaning up after this.
Attachment #352253 - Flags: superreview?(dbaron)
Attachment #352253 - Flags: superreview+
Attachment #352253 - Flags: review?(dbaron)
Attachment #352253 - Flags: review+
Ah ha, I've been seeing this one a lot when running Fennec. Thanks for fixing it! :)
Flags: blocking1.9.1? → blocking1.9.1+
Whiteboard: [needs review] → [needs landing]
I've hit this a few times today already. We'd better get a fix landed ASAP
Keywords: checkin-needed
Comment on attachment 352253 [details] [diff] [review]
[Checkin: Comment 5 & 8]
Attachment #352253 - Attachment description: fix → fix [Checkin: Comment 5]
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [c-n: baking for 1.9.1] [needs landing]
Target Milestone: --- → mozilla1.9.2a1
Comment on attachment 352253 [details] [diff] [review]
[Checkin: Comment 5 & 8]

Does not apply to 1.9.1:
patching file view/src/nsViewManager.cpp
Hunk #1 FAILED at 2409
1 out of 1 hunks FAILED
Keywords: checkin-needed
Whiteboard: [c-n: baking for 1.9.1] [needs landing]
Yes, the patch that caused this regression (in bug 302561) hasn't landed in 1.9.1.
Whiteboard: [blocking1.9.1+, but see comment 7 first]
Fixed on 1.9.1 (landed along with bug 302561):
Keywords: fixed1.9.1
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1b3
Keywords: regression
Whiteboard: [blocking1.9.1+, but see comment 7 first]
Attachment #352253 - Attachment description: fix [Checkin: Comment 5] → fix [Checkin: Comment 5 & 8]
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.