304262 - crash [@ nsDOMUIEvent::GetClientPoint] when dragging DHTML clock

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect)

Description

[Adam Guthrie]

GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
GetPrimaryFrameFor() called while nsFrameManager is being destroyed!
[Thread -1231823952 (LWP 8804) exited]
###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().:
'mRawPtr != 0', file ../../dist/include/xpcom/nsCOMPtr.h, line 849
Break: at file ../../dist/include/xpcom/nsCOMPtr.h, line 849

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208326480 (LWP 8800)]
0x01a95f48 in nsDOMUIEvent::GetClientPoint (this=0xa27948c)
    at /home/aguthrie/moz/mozilla/content/events/src/nsDOMUIEvent.cpp:183
183         nsCOMPtr<nsIWidget> t = dont_AddRef(docParent->GetParent());
(gdb) b
Breakpoint 1 at 0x1a95f48: file
/home/aguthrie/moz/mozilla/content/events/src/nsDOMUIEvent.cpp, line 183.
(gdb) bt
#0  0x01a95f48 in nsDOMUIEvent::GetClientPoint (this=0xa27948c)
    at /home/aguthrie/moz/mozilla/content/events/src/nsDOMUIEvent.cpp:183
#1  0x01a96499 in nsDOMUIEvent::GetPageX (this=0xa27948c, aPageX=0xbfdb8c4c)
    at /home/aguthrie/moz/mozilla/content/events/src/nsDOMUIEvent.cpp:275
#2  0x001dc795 in XPTC_InvokeByIndex ()
    at
/home/aguthrie/moz/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:48
#3  0x00ec0722 in XPCWrappedNative::CallMethod (ccx=@0xbfdb8e48,
    mode=XPCWrappedNative::CALL_GETTER)
    at /home/aguthrie/moz/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2119
#4  0x00eccbe5 in XPCWrappedNative::GetAttribute (ccx=@0xbfdb8e48)
    at /home/aguthrie/moz/mozilla/js/src/xpconnect/src/xpcprivate.h:1918
#5  0x00ec93bf in XPC_WN_GetterSetter (cx=0xa00fb98, obj=0x9cf7ed0, argc=0,
    argv=0xa30e9cc, vp=0xbfdb8f94)
    at
/home/aguthrie/moz/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cp---Type
<return> to continue, or q <return> to quit---
p:1433
#6  0x00c16ed0 in js_Invoke (cx=0xa00fb98, argc=0, flags=2)
    at /home/aguthrie/moz/mozilla/js/src/jsinterp.c:1173
#7  0x00c172ba in js_InternalInvoke (cx=0xa00fb98, obj=0x9cf7ed0,
    fval=166018624, flags=0, argc=0, argv=0x0, rval=0xbfdb99f4)
    at /home/aguthrie/moz/mozilla/js/src/jsinterp.c:1270
#8  0x00c17562 in js_InternalGetOrSet (cx=0xa00fb98, obj=0x9cf7ed0,
    id=169097512, fval=166018624, mode=JSACC_READ, argc=0, argv=0x0,
    rval=0xbfdb99f4) at /home/aguthrie/moz/mozilla/js/src/jsinterp.c:1313
#9  0x00c4228e in js_GetProperty (cx=0xa00fb98, obj=0x9cf7ed0, id=169097512,
    vp=0xbfdb99f4) at /home/aguthrie/moz/mozilla/js/src/jsobj.c:2843
#10 0x00c269ff in js_Interpret (cx=0xa00fb98, pc=0xa0a3bc9 "5",
    result=0xbfdb9da0) at /home/aguthrie/moz/mozilla/js/src/jsinterp.c:3290
#11 0x00c16f4b in js_Invoke (cx=0xa00fb98, argc=1, flags=2)
    at /home/aguthrie/moz/mozilla/js/src/jsinterp.c:1193
#12 0x00c172ba in js_InternalInvoke (cx=0xa00fb98, obj=0x9e35620,
---Type <return> to continue, or q <return> to quit---
    fval=166018128, flags=0, argc=1, argv=0xbfdba0cc, rval=0xbfdba0bc)
    at /home/aguthrie/moz/mozilla/js/src/jsinterp.c:1270
#13 0x00be1580 in JS_CallFunctionValue (cx=0xa00fb98, obj=0x9e35620,
    fval=166018128, argc=1, argv=0xbfdba0cc, rval=0xbfdba0bc)
    at /home/aguthrie/moz/mozilla/js/src/jsapi.c:3919
#14 0x01bbe30d in nsJSContext::CallEventHandler (this=0x9bd4f20,
    aTarget=0x9e35620, aHandler=0x9e53c50, argc=1, argv=0xbfdba0cc,
    rval=0xbfdba0bc)
    at /home/aguthrie/moz/mozilla/dom/src/base/nsJSEnvironment.cpp:1400
#15 0x01c1c520 in nsJSEventListener::HandleEvent (this=0x9f88958,
    aEvent=0xa279498)
    at /home/aguthrie/moz/mozilla/dom/src/events/nsJSEventListener.cpp:176
#16 0x01a7c7e3 in nsEventListenerManager::HandleEventSubType (this=0xa0ed5d0,
    aListenerStruct=0xa361648, aDOMEvent=0xa279498, aCurrentTarget=0xa22cf68,
    aSubType=1, aPhaseFlags=2)
    at
/home/aguthrie/moz/mozilla/content/events/src/nsEventListenerManager.cpp---Type
<return> to continue, or q <return> to quit---
:1594
#17 0x01a7e6a4 in nsEventListenerManager::HandleEvent (this=0xa0ed5d0,
    aPresContext=0xa2cbc90, aEvent=0xbfdbad20, aDOMEvent=0xbfdba7e8,
    aCurrentTarget=0xa22cf68, aFlags=2, aEventStatus=0xbfdbaab0)
    at /home/aguthrie/moz/mozilla/content/events/src/nsEventListenerManager.cpp:1695
#18 0x01a135a7 in nsDocument::HandleDOMEvent (this=0xa22ceb8,
    aPresContext=0xa2cbc90, aEvent=0xbfdbad20, aDOMEvent=0xbfdba7e8,
    aFlags=2, aEventStatus=0xbfdbaab0)
    at /home/aguthrie/moz/mozilla/content/base/src/nsDocument.cpp:3991
#19 0x01a3cb3b in nsGenericElement::HandleDOMEvent (this=0xa3af610,
    aPresContext=0xa2cbc90, aEvent=0xbfdbad20, aDOMEvent=0xbfdba7e8,
    aFlags=2, aEventStatus=0xbfdbaab0)
    at /home/aguthrie/moz/mozilla/content/base/src/nsGenericElement.cpp:2163
#20 0x01a3caf2 in nsGenericElement::HandleDOMEvent (this=0xa231160,
    aPresContext=0xa2cbc90, aEvent=0xbfdbad20, aDOMEvent=0xbfdba7e8,
---Type <return> to continue, or q <return> to quit---
    aFlags=2, aEventStatus=0xbfdbaab0)
    at /home/aguthrie/moz/mozilla/content/base/src/nsGenericElement.cpp:2155
#21 0x01a3caf2 in nsGenericElement::HandleDOMEvent (this=0xa0b5420,
    aPresContext=0xa2cbc90, aEvent=0xbfdbad20, aDOMEvent=0xbfdba7e8,
    aFlags=7, aEventStatus=0xbfdbaab0)
    at /home/aguthrie/moz/mozilla/content/base/src/nsGenericElement.cpp:2155
#22 0x017d4c77 in PresShell::HandleEventInternal (this=0xa0a02f8,
    aEvent=0xbfdbad20, aView=0xa2bc528, aFlags=1, aStatus=0xbfdbaab0)
    at /home/aguthrie/moz/mozilla/layout/base/nsPresShell.cpp:6365
#23 0x017d60c3 in PresShell::HandleEvent (this=0xa0a02f8, aView=0xa2bc528,
    aEvent=0xbfdbad20, aEventStatus=0xbfdbaab0, aForceHandle=0,
    aHandled=@0xbfdbaa9c)
    at /home/aguthrie/moz/mozilla/layout/base/nsPresShell.cpp:6201
#24 0x01bb5988 in nsViewManager::HandleEvent (this=0x9ec2a90,
    aView=0xa013848, aEvent=0xbfdbad20, aCaptured=0)
    at /home/aguthrie/moz/mozilla/view/src/nsViewManager.cpp:2565
---Type <return> to continue, or q <return> to quit---
#25 0x01bb67fb in nsViewManager::DispatchEvent (this=0x9ec2a90,
    aEvent=0xbfdbad20, aStatus=0xbfdbac60)
    at /home/aguthrie/moz/mozilla/view/src/nsViewManager.cpp:2246
#26 0x01ba6799 in HandleEvent (aEvent=0xbfdbad20)
    at /home/aguthrie/moz/mozilla/view/src/nsView.cpp:171
#27 0x00b7dbb1 in nsCommonWidget::DispatchEvent (this=0x9f569c8,
    aEvent=0xbfdbad20, aStatus=@0xbfdbad68)
    at /home/aguthrie/moz/mozilla/widget/src/gtk2/nsCommonWidget.cpp:219
#28 0x00b6f3a5 in nsWindow::OnMotionNotifyEvent (this=0x9f569c8,
    aWidget=0xa1bd520, aEvent=0x9cfdfa0)
    at /home/aguthrie/moz/mozilla/widget/src/gtk2/nsWindow.cpp:1472
#29 0x00b6fe2a in motion_notify_event_cb (widget=0xa1bd520, event=0x9cfdfa0)
    at /home/aguthrie/moz/mozilla/widget/src/gtk2/nsWindow.cpp:3663
#30 0x007d7352 in gtk_marshal_VOID__UINT_STRING ()
   from /usr/lib/libgtk-x11-2.0.so.0
#31 0x002ee285 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#32 0x002fc78b in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0
#33 0x002fdc53 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#34 0x002fe254 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#35 0x008b2ac3 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0
#36 0x007d5ab7 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#37 0x007d5ef4 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#38 0x0064fd6e in gdk_screen_get_setting () from /usr/lib/libgdk-x11-2.0.so.0
#39 0x003453ee in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#40 0x003483f6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#41 0x003486e3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#42 0x007d51b5 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#43 0x00b7b152 in nsAppShell::Run (this=0x9b96940)
    at /home/aguthrie/moz/mozilla/widget/src/gtk2/nsAppShell.cpp:139
#44 0x024901b9 in nsAppStartup::Run (this=0x9b968f8)
    at
/home/aguthrie/moz/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:145
---Type <return> to continue, or q <return> to quit---
#45 0x08052340 in XRE_main (argc=1, argv=0xbfdbb7c4, aAppData=0x806c160)
    at /home/aguthrie/moz/mozilla/toolkit/xre/nsAppRunner.cpp:2324
#46 0x0804b28a in main (argc=1, argv=0xbfdbb7c4)
    at /home/aguthrie/moz/mozilla/browser/app/nsBrowserApp.cpp:61

Happened when I was trying to drag the clock around on the page.

Comment 1

[John Sullivan]

Attachment: be more careful about null pointers

I can't duplicate this crash under either DPA1 or DPA2. More detail required,
perhaps? Or maybe you just have to be unlucky and poke it at exactly the wrong
moment...

In any case, it appears that at least once in the failing routine docWidget has
come back null. I've no idea whether this is to be expected on occasion or
indicates a bug elsewhere, but it is easy enough to guard against here.

Comment 2

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050814 Firefox/1.0+
ID:2005081410

Just reproduced with a clean profile. stephend also reproduced this on Windows:
TB8239742.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'd like to understand what's really going on here before we start papering over
cracks. We need a reduced testcase...

Comment 4

[Martijn Wargers (dead)]

I especially crash easy, when I do click - mousedown - drag quickly after each
other on the dhtml clock. Talkback ID's: TB8616505X TB8616461K

Comment 5

[Martijn Wargers (dead)]

I'm pretty sure the regression range is between 2005-07-19 and 2005-07-20:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-07-19+07%3A00%3A00&maxdate=2005-07-20+08%3A00%3A00&cvsroot=%2Fcvsroot
It's very likely a regression from fixing bug 296004, I think. Especially when I
look at the attached patch ("be more careful about null pointers") here.

What I forgot to say in comment 4, you have to drag the image into the iframe to
get the crash.
I haven't been able to get a minimised testcase, yet. Might take me a while (if
I ever succeed in it).

Comment 6

[John Sullivan]

Well, the crash is certainly made possible here by my original patch to bug
296004, and the patch I present to this bug returns us to basically the status
quo (except with bug 296004 still fixed).

However I think there is something else going on. The crash happens because
docWidget on occasion appears to come back null. I'm not convinced this ever
makes sense: we're being asked to process a mouse event within a HTML document,
and the null docWidget means we can't figure out which document we're supposed
to be processing it for! We can cover up the crash and pretend all is well
again, but that doesn't change the fact that some other part of the code isn't
behaving well and is probably causing other less obvious artifacts.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> we're being asked to process a mouse event within a HTML document

These can be synthesized in JS, in which case they will have no widget...

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

In my testing it appears that we crash because the presshell is null, so we
never set docWidget. I would really like to know why we're processing an event
with no presshell. Is the event being handled in an IFRAME and the event handler
destroys the IFRAME, perhaps?

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

In the meantime, we should think about what to do if someone askes for the pageX
or whatever of an event whose presentation has been torn down. CCing Ian since
this is really a DOM standards/Web compatibility question.

Comment 10

[S. Ali Tokmen]

(In reply to comment #8)
> Is the event being handled in an IFRAME and the event handler
> destroys the IFRAME, perhaps?

I suppose not since for the iFrame to get destroyed the user needs to click 
the "x" button on the top right corner or to choose some other option in the 
main menu (and doing so will stop all drag actions)

Mouse handling in the iframe is required since the iFrame doesn't belong to the 
main page yet it should not loose the drag (mouse movement) when the clock goes 
on an iFrame.

One question: what version of Mozilla / Firefox is experiencing the problem? 
I've tested on lots of versions from Firefox .7 to the latest public Firefox 
and haven't been able of reproducing the bug (note that I didn't try with 
any "nightly release")

Comment 11

[Boris Zbarsky [:bzbarsky]]

> I suppose not since for the iFrame to get destroyed the user needs to click 
> the "x" button on the top right corner or to choose some other option in the 
> main menu (and doing so will stop all drag actions)

No, iframes can get destroyed by all sorts of things including DOM events.

> (note that I didn't try with any "nightly release")

Please do try.  Testing with anything from the 1.0 branch is really quite
pointless at this juncture...

Comment 12

[Martijn Wargers (dead)]

Attachment: testcase

I managed to make a fairly simple testcase.
I've made the iframe quite large, because I think it crashes easier that way.

The iframe document consists only of this script basically:
document.onmousemove=function(){var x=document.body.offsetHeight}

Follow the steps in the testcase to trigger the crash. It should normally crash
fairly easy (within 3 tries or so).

Comment 13

[Scott MacGregor]

I'm tempted to put this on the blocker list since it looks like a regression
crash. Jay, is this crash showing up a lot in talkback?

Comment 14

[Asa Dotzler [:asa]]

pretty low on the topcrash list for 1.5 beta (only 4 incidents). If we get a low
risk fix, we might consider for approval but not going to block on this.

Comment 15

[Jay Patel [:jay]]

This is definitely not a "topcrasher", but as always, if we have a reproducible
testcase and a patch for a "low risk" fix, we should consider getting this in
for the next Beta.

I am not able to crash with the testcase in this bug...has anyone else had any
luck?  Is there a trick to it?  I'm using the Beta 1 build: Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 (No IDN) Firefox/1.4

Comment 16

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050913 Firefox/1.6a1
ID:2005091307

I couldn't crash with the testcase earlier either, but when I tried today I got
it. The only thing is that it's not crashing at nsDOMUIEvent::GetClientPoint
anymore; it's crashing at nsEventStateManager::SetContentState (both with the
testcase and on the bug URL). Not sure if I need to open a new bug or not...
TB9316481H

Comment 17

[Boris Zbarsky [:bzbarsky]]

The stack for that incident is completely bogus.  At a guess, the talkback
server is using the wrong symbols or something...

Comment 18

[Adam Guthrie]

Yeah. Sorry about that. Tried my own debug build and get the same stack trace I
pasted in comment 0. :P

Comment 19

[Martijn Wargers (dead)]

Attachment: testcase

I've managed to get a 100% reproducable crashing testcase (at least for me).
- Open testcase
- Mouse down on the red block
- Move the mouse to the iframe
Result->crash

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No doubt we're crashing because the mouseover handler caused the parent document
to reframe (which is flushed by the reference to offsetHeight!) so the parent
widget(s) have gone away.

I think the thing to do here --- not just to avoid crashes, but to preserve
sanity when the frame tree changes while we have an active event --- is to
compute and save clientPoint (and, I think, screenPoint) when we create a
DOMUIEvent, and not look at the widget afterward.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The perfectly branch-safe fix is a little bit complicated because there's
already an mClientPoint stored and used in some cases when there is no widget,
and preserving that behaviour exactly is a bit annoying.

Eli, this is not your bug, but fixing this is within the penumbra of what you've
been working on :-).

Comment 22

[Francis Chin]

The testcase crashes for me on W2K (TB12007487X) and Linux (TB12008485E).

I think this bug also affects http://www.trafficmap.co.uk/ - click on a map square that has an incident in it (pick London, there's always traffic there...), then when the detailed map appears, mouseover an icon. A 'tooltip' information box should appear next to the pointer, but instead we get a crash (TB11807741G). For some reason this does not cause a crash under Linux, even though the testcase works.

Comment 23

[Stephen Donner [:stephend] Not actively reading bugmail]

I no longer crash with build 2006-01-16-09 of SeaMonkey under Windows XP with testcase: https://bugzilla.mozilla.org/attachment.cgi?id=195934&action=view

Martijn/Adam, how about you guys?

Comment 24

[Martijn Wargers (dead)]

Indeed, I don't crash anymore either.
This seems to have been fixed somewhere between 2005-12-29 and 2006-01-06.

Comment 25

[Adam Guthrie]

This got fixed between 2006-01-04 05:00 and 2006-01-05 05:00.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-01-04+04&maxdate=2006-01-05+06&cvsroot=%2Fcvsroot

I'd really like to mark this FIXED. Maybe the patches in bug 322128 or bug 306959 fixed this?

Comment 26

[Francis Chin]

Managed to get a recent Firefox nightly up (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060116 Firefox/1.6a1) and I don't see the problem anymore with either the testcase or the http://www.trafficmap.co.uk/ site.

Comment 27

[Martijn Wargers (dead)]

Comment on attachment 192675 [details] [diff] [review]
be more careful about null pointers

Removing review request, since the crash no longer occurs.

Comment 28

[Francis Chin]

The testcase actually crashes for me now (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6) - although the trafficmap web site does not show up any problems.

Can anyone else replicate the crash with the testcase?

Comment 29

[Adam Guthrie]

Yeah, apparently the crash is still happening on 1.5.0.x. There's a patch in bug 336576 that should fix it. (It's waiting to be approved to land on the 1.8.x and 1.8.0.x branches.)