115764 - sporadic Trunk crashes in [@ nsWindow::OnDragMotionSignal] w/drag'n'drop

Status: VERIFIED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[sairuh (rarely reading bugmail)]

i've encountered crashes several times today using 2001.12.17.08 comm linux bits
when:

* dragging a mail message into another folder [3pane window]
* dragging a link from one tabbed browser to another

it doesn't happen *all* the time, alas, but it's been frequent enough (at least
four times today) that it should be filed...

talkback reports look the same:

nsWindow::OnDragMotionSignal()
nsWindow::FireDragMotionTimer()
nsWindow::DragMotionTimerCallback()
nsTimerImpl::Process()
handleMyEvent()
PL_HandleEvent()
PL_ProcessEventsBeforeID()
processQueue()
nsVoidArray::EnumerateForwards()
nsAppShell::ProcessBeforeID()
handle_gdk_event()
libgdk-1.2.so.0 + 0x17d7f (0x40357d7f)
libglib-1.2.so.0 + 0x11773 (0x4038b773)
libglib-1.2.so.0 + 0x11d39 (0x4038bd39)
libglib-1.2.so.0 + 0x11eec (0x4038beec)
libgtk-1.2.so.0 + 0x94333 (0x402a6333)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1c507 (0x404d1507)

Comment 1

[sairuh (rarely reading bugmail)]

have you seen this recently, terri?

Comment 2

[Robert Ginda]

I'm seeing this alot on my 12/17 nightly.  cc'ing pav because timers are on the
stack.

Comment 3

[Robert Ginda]

http://climate/reports/searchstacksignature.cfm?stacksig=nsWindow%3A%3AOnDragMotionSignal

talkback shows these crashes starting on the 16th, and still going strong.

Comment 4

[Stuart Parmenter]

I saw this.. It looked like it was due to one of the window's member variables
was null... perhaps mDragMotionContext. The only significant change to timers on
unix is that now timers don't fire as gtk events but isntead as plevents.

Comment 5

[sairuh (rarely reading bugmail)]

jay or janc, have you seen these crashes cropping up more frequently lately?

Comment 6

[Jay Patel [:jay]]

Talkback data shows there were 7 crashes with 12/16 builds and 25 with 12/17
builds.  There doesn't appear to be any crashes with 12/18 builds...so we'll
have to wait and see if this is still crashing with the most recent MozillaTrunk
builds.

Comment 7

[Jay Patel [:jay]]

Adding topcrash keyword and Trunk to summary for tracking since there have been
quite a few crashes in recent builds.

Comment 8

[sairuh (rarely reading bugmail)]

jay, are the crashes limited to Linux, or are they occurring in other platforms too?

Comment 9

[Jay Patel [:jay]]

sairuh: this looks like a linux specific crash...talkback doesn't show any
incidents with the "nsWindow::OnDragMotionSignal" stack signature for windows or
mac.  it might be happening on other platforms...but in that case the stack
signature must be different.  

has anyone experienced this crash on those platforms?  if so it would be
interesting to find out what stack signature is being reported for windows and mac.

Comment 10

[Christopher Blizzard (:blizzard)]

I'll bet that this is because we're not using gtk timers anymore so the event
ordering is all screwed up.  The timers used to take precedence over native X
and other events in the mainloop.  I'll bet this is happening because the timers
are firing after the event that would have removed it or something.  It might be
worth it to try to move it to a native gtk timer to get the proper event
ordering here.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is the #1 topcrash for the period 12-20 to 12-23, even though it only
happens on Linux.  Should this really be assigned to blake?

Comment 12

[Brendan Eich [:brendan]]

This is pavlov's.  I'll look at it while he's on vacation; I'll probably need
blizzard's help.

/be

Comment 13

[Christopher Blizzard (:blizzard)]

Attachment: patch to use "native" timers

Comment 14

[Christopher Blizzard (:blizzard)]

Attachment: round 2 - fight!

This patch returns FALSE from the timer callback, cancelling the timer.

Comment 15

[Christopher Blizzard (:blizzard)]

Attachment: patch 3

This patch removes the extra mDragMotionTimer member variable.

Comment 16

[Olav Vitters]

Oops. I didn't get a midair. I only CC'd myself at 115520. Readding block 115520.

Comment 17

[Jim Crumley]

*** Bug 117382 has been marked as a duplicate of this bug. ***

Comment 18

[Blu3]

This bug is slightly different from 117382 according to both poster's comments.
 I experience 100% reproducible crashes like bug 117382.  Is this caused by the
same code?

Comment 19

[Blu3]

Just for the record, it doesn't matter what object is picked up, text, img, etc,
if it is dropped onto it's self, moz crashes.

Comment 20

[Christopher Blizzard (:blizzard)]

david, have you tried this patch?

Comment 21

[iraqispy]

Incidentally, if bug 117382 is indeed a duplicate of this, you don't need
to drop the selected object on itself.  You can either drop it anywhere in
the window, or drag it out of the window (without dropping).

Comment 22

[Dan Mosedale (:dmosedale, :dmose)]

Easy-to-reproduce test case: 

* go to a folder in an imap server
* select a message
* forward it
* one-by-one, drag additional messages from that folder into the attachments
pane of the compose window of the forwarded msg
* after 2 or 3 drags, this crash will happen

Comment 23

[Christopher Blizzard (:blizzard)]

I tried this with and without the patch in this bug and it seems to fix the
crash.  dmose, is that your experience as well?

Comment 24

[Brian Ryner (not reading)]

Comment on attachment 62919 [details] [diff] [review]
patch 3

r=bryner

Comment 25

[Mike Shaver (:shaver emeritus)]

Comment on attachment 62919 [details] [diff] [review]
patch 3

sr=shaver

(4! FOUR!)

Comment 26

[Dan Mosedale (:dmosedale, :dmose)]

Patch 3 does appear to fix this for me, yes.

Comment 27

[Christopher Blizzard (:blizzard)]

Checked in.  Rock on.

Comment 28

[Christopher Blizzard (:blizzard)]

Oh, fixed.

Comment 29

[Blake Ross]

*** Bug 116419 has been marked as a duplicate of this bug. ***

Comment 30

[Blake Ross]

*** Bug 117619 has been marked as a duplicate of this bug. ***

Comment 31

[Blake Ross]

*** Bug 114664 has been marked as a duplicate of this bug. ***

Comment 32

[greer]

No talkback data with buildIDs after the checkin. VERIFIED.