336586 - Crash when window gets destroyed when dragdropping something in iframe

Status: VERIFIED FIXED

(Core :: Widget, defect)

Description

[Martijn Wargers (dead)]

This could be related to bug 300675.
See upcoming testcase, which crashes current Mozilla builds when dragdropping some text in the textarea.

This regressed between 2004-11-07 and 2004-11-10 (Ria, you have builds in between?):
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=2004-11-07+08&maxdate=2004-11-10+09&cvsroot=%2Fcvsroot
I guess bug 219400 could be a possible culprit.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Martijn Wargers (dead)]

Talkback ID: TB18285312X
nsNativeDragTarget::Drop   ole32.dll + 0xea0f9 (0x7725a0f9)
ole32.dll + 0xea31f (0x7725a31f)
ole32.dll + 0xb1f0e (0x77221f0e)
ole32.dll + 0xb1dc7 (0x77221dc7)
nsDragService::StartInvokingDragSession   nsDragService::InvokeDragSession   0x0012eed8
nsAutoCMonitor::operator new   0xfffffe59

Comment 3

[Ria Klaassen (not reading all bugmail)]

Build ID=2004110806 crashes.

Comment 4

[Martijn Wargers (dead)]

Thanks Ria, that makes bug 219400 a more likely candidate.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Martijn, this looks to be Windows-only.  Can you get this in a debugger?  If so, are we crashing in nsNativeDragTarget::Drop?  On which line?

My guess would be that we're on line 360, mDragService is null and we need to hold a local nsCOMPtr to the drag service in that method because ProcessDrag destroys us or something....

Comment 6

[:Gijs (he/him)]

(In reply to comment #5)
> My guess would be that we're on line 360, mDragService is null and we need to
> hold a local nsCOMPtr to the drag service in that method because ProcessDrag
> destroys us or something....

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB18350240E

Seems to indicate you're right there, since the top frame is indeed ::Drop, line 360.

I'm afraid I don't know anything else, but it seems you've figured it out :-)

Comment 7

[Frank Wein [:mcsmurf]]

Making it use "nsCOMPtr<nsIDragService> serv = mDragService;[...]serv->EndDragSession();" did not help here. I'll attach a stacktrace from a debug build here (with this patch included) since it looks a bit different.

Comment 8

[Frank Wein [:mcsmurf]]

Attachment: Stacktrace

Comment 9

[Boris Zbarsky [:bzbarsky]]

So.. that's not the same stack as others were seeing for this bug, right?  I wouldn't be surprised if that only actually crashes reliably in debug builds, and only sometimes in others.

Frank, I'll post a patch for you to try; lemme know whether it helps?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to test

Comment 11

[Frank Wein [:mcsmurf]]

No, this patch does not seem to help, the stacktrace on crash is still the same.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch for my first suggestion

Comment 13

[Mike Connor [:mconnor]]

That patch fixes the crash on my trunk opt build.

Comment 14

[Darin Fisher]

Comment on attachment 221106 [details] [diff] [review]
Patch for my first suggestion

Hrm... maybe move this down just before ProcessDrag is called?  sr=darin

Comment 15

[Ere Maijala (slow)]

Comment on attachment 221106 [details] [diff] [review]
Patch for my first suggestion

Agreed, move it down a bit to be more clear.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.  I think we want this on branches....

Comment 17

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch updated to comments

Comment 18

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

Verified FIXED using build 2006-05-12-07 of SeaMonkey trunk under Windows XP with the testcase: https://bugzilla.mozilla.org/attachment.cgi?id=220769.

No crash.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Fixed on 1.8 branch.

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 221778 [details] [diff] [review]
Patch updated to comments

approved for 1.8.0 branch, a=dveditz for drivers

Comment 21

[Boris Zbarsky [:bzbarsky]]

Fixed for 1.8.0.5.

Comment 22

[Tracy Walker [:tracy]]

verified with Windows Fx 2.0b2 build from 22060821