Closed Bug 300675 Opened 19 years ago Closed 16 years ago

Drop event crashes mozilla [@ nsWindow::OnDragDropSignal][@ nsNativeDragTarget::Drop]

Categories

(Core :: Widget, defect)

Product:
Core
Component:
Widget
Version:
1.7 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: sean, Unassigned)

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

Testcase extension
1.68 KB, application/x-xpinstall
Details
deer park version of extension
2.22 KB, application/x-xpinstall
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414

When 

Reproducible: Always

Steps to Reproduce:
1. Install xpi :-o
2. load chrome://testcase/content/dnd.xul
3. Drag label onto button

Actual Results:  
crash

Expected Results:  
deleted the button

The drop event bubbles up from the button to the groupbox. The handler on the
groupbox deletes the button. Mozilla crashes.
This xpi isn't causing a crash. It experiences NS_ERROR_FAILUREs before it gets
to the part where it crashes.
OK... what would cause the crash?
This is branch-only? Certainly it doesn't crash my trunk build.

Note: I was unable to drop anything dragged from the label.
However, I was able to select random text and drop it on the button.
The NS_ERROR_FAILUREs are corrected. You can now drag the label onto the groupbox.

However, it doesn't crash :-S  This is a pretty poor testcase.
Talkbacks TB7423146Q and TB7515464G relate to actual crashes.
ok. it seems that the crash is related to trees.
The testcase now uses a tree as the drop target, and it does crash.
Yhe native drag event gets freed during ProcessDrag();
Adding a kung fu death grip prevents the crash.
Incident ID: 7423146 
Stack Signature 0x000000c9 56c7422a 
Product ID Mozilla17 
Build ID 2005041417 
Trigger Time 2005-07-12 13:08:25.0 
Platform LinuxIntel 
Operating System Linux 2.4.20-37_40.rh9.at 
Module  
URL visited  
User Comments dragged treeitem from one tree to another. On drop, browser 
crashed, but the drop event completed successfully. 
Since Last Crash 0 sec 
Total Uptime 140 sec 
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11) 
Source File, Line No. N/A 
Stack Trace  

0x000000c9
nsWindow::OnDragDropSignal()  [/builds/tinderbox/Mozilla1.7/Linux_2.4.18-
3_Clobber/mozilla/widget/src/gtk/nsWindow.cpp, line 3432]
nsWindow::DragDropSignal()  [/builds/tinderbox/Mozilla1.7/Linux_2.4.18-
3_Clobber/mozilla/widget/src/gtk/nsWindow.cpp, line 3329]
libgtk-1.2.so.0 + 0xa1cfb (0x401e1cfb)
libgtk-1.2.so.0 + 0xda015 (0x4021a015)
libgtk-1.2.so.0 + 0xd916d (0x4021916d)
libgtk-1.2.so.0 + 0xd6ec5 (0x40216ec5)
libgtk-1.2.so.0 + 0x69f35 (0x401a9f35)
libgtk-1.2.so.0 + 0x694bc (0x401a94bc)
libgtk-1.2.so.0 + 0x68b34 (0x401a8b34)
libgtk-1.2.so.0 + 0xa0a75 (0x401e0a75)
handle_gdk_event()  [/builds/tinderbox/Mozilla1.7/Linux_2.4.18-
3_Clobber/mozilla/widget/src/gtk/nsGtkEventHandler.cpp, line 863]
libgdk-1.2.so.0 + 0x18f15 (0x402a1f15)
libglib-1.2.so.0 + 0x119ae (0x402d59ae)
libglib-1.2.so.0 + 0x11e89 (0x402d5e89)
libglib-1.2.so.0 + 0x12124 (0x402d6124)
libgtk-1.2.so.0 + 0xa027f (0x401e027f)
nsAppShell::Run()  [/builds/tinderbox/Mozilla1.7/Linux_2.4.18-
3_Clobber/mozilla/widget/src/gtk/nsAppShell.cpp, line 319]
nsAppShellService::Run()  [/builds/tinderbox/Mozilla1.7/Linux_2.4.18-
3_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 524]
main1()  [/builds/tinderbox/Mozilla1.7/Linux_2.4.18-
3_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 710]
main()  [/builds/tinderbox/Mozilla1.7/Linux_2.4.18-
3_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1784]
libc.so.6 + 0x15ab7 (0x40416ab7)
Severity: normal → critical
Keywords: crash
Summary: Drop event crashes mozilla → Drop event crashes mozilla [@ nsWindow::OnDragDropSignal]
Why shouldn't the drag event get freed?
At the time of the crash, the drop event handler is done interacting with the
dragged object.

Also why does it crash on trees, but not buttons, or groupboxes, etc.?
(In reply to comment #9)
>Why shouldn't the drag event get freed?
>At the time of the crash, the drop event handler is done interacting with the
>dragged object.
Well, I was debugging on windows, because I find debugging drag-n-drop on Linux
a pain, but the windows drag target object tries to reference a member variable
after the drop has completed. However something frees the object before then so
that the member variable contains garbage.
Neil, want to just patch this?
I'm not honestly sure where to patch it, as the crash happens in platform code.
Talkback TB7626667Q is a crash from Windows
In fact, I guess that the crash happens in gtk's nsWindow.cpp because the
dispatch of the OnDragLeave destroys the nsWindow before it gets to set
mLastDragMotionWindow to 0. A similar issue occurs in windows's nsWindow.cpp
because the dispatch of dispatch of ProcessDrag destroys the nsNativeDragTarget
before it gets to call mDragService->EndDragSession(). There may be others...
Incident ID: 7626667
Stack Signature	nsNativeDragTarget::Drop 0a7e6414
Product ID	Firefox10
Build ID	2005051112
Trigger Time	2005-07-19 14:58:56.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (001185a9)
URL visited	
User Comments	d&d onto tree
Since Last Crash	2678660 sec
Total Uptime	2678660 sec
Trigger Reason	Access violation
Source File, Line No.
d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsNativeDragTarget.cpp,
line 350
Stack Trace 	
nsNativeDragTarget::Drop 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsNativeDragTarget.cpp,
line 350]
ole32.dll + 0x118e86 (0x775f8e86)
ole32.dll + 0x1190c8 (0x775f90c8)
ole32.dll + 0xefc98 (0x775cfc98)
ole32.dll + 0xefb20 (0x775cfb20)
nsDragService::StartInvokingDragSession 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsDragService.cpp,
line 168]
nsDragService::InvokeDragSession 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsDragService.cpp,
line 133]
XPTC_InvokeByIndex 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2034]
XPC_WN_CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1781]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 955]
js_Interpret 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 2999]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 972]
js_InternalInvoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1049]
JS_CallFunctionValue 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 3698]
nsJSContext::CallEventHandler 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1297]
nsJSEventListener::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsEventListenerManager::HandleEventSubType 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1516]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2841]
nsEventStateManager::GenerateDragGesture 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 1484]
nsEventStateManager::PreHandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 443]
PresShell::HandleEventInternal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6056]
PresShell::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5921]
nsViewManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2326]
nsViewManager::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2066]
HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsView.cpp,
line 77]
nsWindow::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1067]
nsWindow::DispatchMouseEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5261]
ChildWindow::DispatchMouseEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5511]
nsWindow::WindowProc 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1349]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0x89cd (0x77d489cd)
USER32.dll + 0x8a10 (0x77d48a10)
nsAppShell::Run 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsAppShell.cpp,
line 159]
nsAppShellService::Run 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 495]
main 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 58]
kernel32.dll + 0x16d4f (0x7c816d4f)
Assignee: jag → general
Component: XP Apps → Widget
Product: Mozilla Application Suite → Core
Summary: Drop event crashes mozilla [@ nsWindow::OnDragDropSignal] → Drop event crashes mozilla [@ nsWindow::OnDragDropSignal][@ nsNativeDragTarget::Drop]
I still think it noteworthy that this bug only surfaces on trees. Buttons,
groupboxes, listboxes, text, etc. don't cause crashes.

Also, will somebody please confirm this bug?
Attached file Testcase extension — 
You have to actually install this as a chrome to for drag and drop to work (or
in this case, work enough to crash).
Alright, it crashes for listboxes, too.
This doesn't crash with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4)
Gecko/20050809 Firefox/1.0+
This doesn't crash in deer park.
Keywords: helpwanted
Works for me, 1.8 branch debug build on Linux (~2.0.0.4pre).
(In reply to comment #14)
> In fact, I guess that the crash happens in gtk's nsWindow.cpp because the
> dispatch of the OnDragLeave destroys the nsWindow before it gets to set
> mLastDragMotionWindow to 0. A similar issue occurs in windows's nsWindow.cpp
> because the dispatch of dispatch of ProcessDrag destroys the nsNativeDragTarget
> before it gets to call mDragService->EndDragSession(). There may be others...

See bug 378273 for the Linux part ?
I don't know about the Windows part.

*****

(1.7 branch is obsolete now.)
R.WorksForMe per "recent" (1.8 branch) comments.
(Reopen if you still have issues with currently supported builds.)
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Keywords: helpwanted
Resolution: --- → WORKSFORME
Flags: in-testsuite?
Crash Signature: [@ nsWindow::OnDragDropSignal] [@ nsNativeDragTarget::Drop]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: