Opened 11 years ago

Closed 11 years ago

#9748 closed defect (fixed)

Crash in wxDropSource::DoDragDrop on Mac (EXC_BAD_ACCESS)

Reported by: csomor Owned by: csomor
Priority: normal Milestone:
Component: old wxOSX/Carbon port Version:
Keywords: Cc: cdegruijter@…
Blocked By: Blocking:
Patch: no

Description

Drag & Drop of wxFileDataObject in this application works reliably on
Windows and
the same Drag & Drop works on Mac (OS X 10.5.4) as expected when - and
only when - the file extension suggests a binary file
(e.g. .jpg, .png, etc) BUT crashes always if the file referenced has
an extension that suggests text content (like .txt, .xpm, etc)

More specifically, it seems to crash at the very first drag event
fired, so that is way before the actually drop.

Furthermore, it has the same crash behavior when filling the
wxFileDataObject from the application itself AND when dragging a file,
e.g. from Finder on to any part of my application window. Similarly,
the crash happens when the mouse pointer hits the very first pixel of
my application window, even when that region is not a drop target.

What is weird (at least to me) is that the wxFileDataObject only
contains file paths . . . so how does the file content play a role in
this? I tested what happened when changing the extension of a binary
file to .txt and from a text file to .png and the crash behavior
consistently follows the file extension. But why would dnd even care
about the extension?

There is no problem when dragging more than 1 file.
There is no problem in the dnd sample either.

wxWidgets version: 2.8.8
OS X version: 10.5.4

Trace when dragging text file within the application window
(gdb) bt
#0  0x96460401 in _SetDstBits32BGRA ()
#1  0x96490e21 in PRBFastPatHiliteRunMask32 ()
#2  0x96453d15 in DevRgn ()
#3  0x96453b25 in StdRgn ()
#4  0x96453880 in CallRgn ()
#5  0x93b9d4e6 in MyDrawingProc ()
#6  0x96481581 in CommonDeviceLoop ()
#7  0x93b9d58c in InvertMyRegion ()
#8  0x93b9d87e in HideDragHilite ()
#9  0x93be2edb in CTextensionDrag::HideDragFeedBack ()
#10 0x93be3470 in CTextensionDrag::DragInWindow ()
#11 0x93be3519 in CTextensionDrag::DragTracking ()
#12 0x93bf781b in OpaqueTXNObject::DragTracking ()
#13 0x93bf785c in CEasyTextDrag::ClientDragTracking ()
#14 0x93be1c8c in MyDragTrackingProc ()
#15 0x93a8e4ca in CarbonTrackingMapper ()
#16 0x963c3540 in DoTrackingMessage ()
#17 0x963c3d80 in SendTrackingMessage ()
#18 0x963c377d in DragInApplication ()
#19 0x963c22de in CoreDragStartDragging ()
#20 0x93a8e28f in TrackDrag ()
#21 0x003e8eea in wxDropSource::DoDragDrop (this=0xbfffe184, flags=0)
at ../src/mac/carbon/dnd.cpp:300
#22 0x00007238 in myFileListCtrl::dragEnd (this=0x2608200,
ds=@0xbfffe184) at /Users/cdg/WorkFolder/SVN/MacBuilds/trunk/
MacBuilds/../../../Library/trunk/Library/Controls/myFilesListCtrl.cpp:
1277


Trace when dragging text file from Finder to application window:
(gdb) bt
#0  0x96460401 in _SetDstBits32BGRA ()
#1  0x96490e21 in PRBFastPatHiliteRunMask32 ()
#2  0x96453d15 in DevRgn ()
#3  0x96453b25 in StdRgn ()
#4  0x96453880 in CallRgn ()
#5  0x93b9d4e6 in MyDrawingProc ()
#6  0x96481581 in CommonDeviceLoop ()
#7  0x93b9d58c in InvertMyRegion ()
#8  0x93b9d87e in HideDragHilite ()
#9  0x93be2edb in CTextensionDrag::HideDragFeedBack ()
#10 0x93be3470 in CTextensionDrag::DragInWindow ()
#11 0x93be3519 in CTextensionDrag::DragTracking ()
#12 0x93bf781b in OpaqueTXNObject::DragTracking ()
#13 0x93bf785c in CEasyTextDrag::ClientDragTracking ()
#14 0x93be1c8c in MyDragTrackingProc ()
#15 0x93a8e4ca in CarbonTrackingMapper ()
#16 0x963c3540 in DoTrackingMessage ()
#17 0x963c5f5e in CoreDragMessageHandler ()
#18 0x9454ef01 in __CFMessagePortPerform ()
#19 0x94570908 in CFRunLoopRunSpecific ()
#20 0x94570cf8 in CFRunLoopRunInMode ()
#21 0x939adda4 in RunCurrentEventLoopInMode ()
#22 0x939adbbd in ReceiveNextEventCommon ()
#23 0x93af0af3 in ReceiveNextEvent ()
#24 0x003ce4d1 in wxApp::MacDoOneEvent (this=0x1b3ce70) at ../src/mac/
carbon/app.cpp:1198
#25 0x003e9bb8 in wxEventLoop::Dispatch (this=0x16c5f6f0) at ../src/
mac/carbon/evtloop.cpp:107
#26 0x00488123 in wxEventLoopManual::Run (this=0x16c5f6f0) at ../src/
common/evtloopcmn.cpp:115
#27 0x0045e10d in wxAppBase::MainLoop (this=0x1b3ce70) at ../src/
common/appcmn.cpp:312
#28 0x0045e27b in wxAppBase::OnRun (this=0x1b3ce70) at ../src/common/
appcmn.cpp:367
#29 0x00357751 in wxEntry (argc=@0xc0fc38, argv=0x1b3c120) at ../src/
common/init.cpp:460
#30 0x00357810 in wxEntry (argc=@0xbffff4f0, argv=0xbffff510) at ../
src/common/init.cpp:

Change History (8)

comment:1 Changed 11 years ago by csomor

  • Status changed from new to accepted

comment:2 Changed 11 years ago by csomor

the same bug seems the root for

http://forum.filezilla-project.org/viewtopic.php?f=2&t=6113&st=0&sk=t&sd=a

thanks to Cees for reporting the facts I've copy/pasted to the entry above

comment:3 Changed 11 years ago by botg

A lot of users of FileZilla have reported this as well, but unfortunately I have never been able to been reproduce this myself and neither did I get enough feedback from affected users.

Two additional reports of the same bug I had to close because issue was unreproducible:
http://sourceforge.net/tracker/index.php?func=detail&aid=1994882&group_id=21558&atid=887596
http://sourceforge.net/tracker/index.php?func=detail&aid=1999435&group_id=21558&atid=887596

From the limited amount of information I've got, it seems that it mostly (only?) affects users of ATI/AMD Radeon graphics cards and/or users with multi-monitor setups. Which I neither have.

comment:4 Changed 11 years ago by csomor

Cees reports back :

Thanks for your response Stefan, you did mention something interesting
about the single/multiple monitors:

wxWidgets version: 2.8.8
OS X version: 10.5.4

MacBook Pro + second monitor (Benq Q22w6) -> crash (both with digital
and analog cable)
MacBook Pro - no second monitor -> it works! no crash!

After the weekend, I'll try to run the program on different iMac's and
another MacBook Pro that still has Tiger installed.

comment:5 Changed 11 years ago by csomor

some more datapoints :

setting a breakpoint in MyDragTrackingProc only seems to trigger in a single line textcontrol, if there's no such control on the window, they don't trigger.

I cannot turn off the installation of these drag handlers for the built-in unicode control, but I can in case we reactivate the mlte-based single-line control for these cases, I've just tested that in fact I can then turn off the installation of the built-in drag handlers (they install themselves on the toplevel window, that's why they crash immediately as soon as something enters the toplevel window)

Best,

Stefan

comment:6 Changed 11 years ago by botg

Another report of the same issue: http://forum.filezilla-project.org/viewtopic.php?p=26578#p26578

Filezilla worked just fine until I plugged in a second monitor. Thats when all the drag and drop issues came about.
With a second monitor plugged in FileZillla crashes whenever i attempt to drag a file from my local system to the remote system. The crash occurs at the moment the drag enters the remote systems tray/window/area...
If i unplug the second monitor, Filezilla works just fine.

comment:7 Changed 11 years ago by csomor

I've committed 54763 and r54764 which seem to eradicate the problem, we wait for Tim's users that experienced the problem to report back

comment:8 Changed 11 years ago by csomor

  • Resolution set to fixed
  • Status changed from accepted to closed

according to reports from Tim's users, the problem doesn't happen anymore.

Note: See TracTickets for help on using tickets.