macOS Drag and Drop causes "illegal hardware instruction" on second drop

[David Woods]

Hello,

I'm using wxPython 4.1.1a1..., a recent daily build on macOS Catalina and Windows 10.  I believe this wxPython is based on wxWidgets 4.1.3.

In my app, users can re-arrange items in a TreeCtrl using drag-and-drop.  This has worked well on Windows but when I drop a tree node the second time on macOS, the program crashes with an "illegal hardware instruction" message.  The crash occurs after execution of the DoDragDrop method is complete.  That is, the drag-and-drop operation is successfully completed before the crash occurs.

I use a CustomDataObject during drag-and-drop.  If I replace the CustomDataObject with a TextDataObject, the program does not crash.  And if I use a CustomDataObject with copy-and-paste through the Clipboard instead of drag-and-drop, the program does not crash.  As a result, I believe there is an interaction between the CustomDataObject and the drag-and-drop system that is behind this error.  And as I say, this only occurs on macOS, with the code working correctly on Windows. Unfortunately, I need to use a CustomDataObject rather than a TextDataObject in my code.

It was also reported on the wxPython mailing list that this crash did not occur using wxPython 4.0.7-post2, a version of wxPython that is not *that* old in the grand scheme of things.  However, I need the later wxPython for some MediaCtrl fixes related to Catalina.  This suggests that the problem was introduced when Robin Dunn upgraded the wxWidgets version he uses to build wxPython for his 4.1 version.

I have included a wxPython sample program.  You can select an item in a TreeCtrl and use either drag-and-drop or cut-and-paste (through the Edit menu) to re-arrange the items in the tree.  You'll see that both methods work on Windows but only copy-and-paste works on macOS, with the program crashing on the second drop using drag-and-drop.  Also, if you alter the boolean value in the first line of the program, the code will use TextDataObject instead of CustomDataObject, and then both cut-and-paste and drag-and-drop will work on both platforms.

I apologize that I don't have a C-based wxWidgets sample for you, but I was unable to get drag-and-drop working in C.

Thanks in advance for looking into this.

David Woods

[Stefan Csomor]

Hi

 

• I apologize that I don't have a C-based wxWidgets sample for you, but I was unable to get drag-and-drop working in C.

 

The problem is that unless I have a c++ based example I won’t be able to debug and help ... I’m sorry

 

Best,

 

Stefan

[Vadim Zeitlin]

On Wed, 29 Jul 2020 17:22:42 -0500 David Woods wrote:

DW> I have included a wxPython sample program. You can select an item in a
DW> TreeCtrl and use either drag-and-drop or cut-and-paste (through the Edit
DW> menu) to re-arrange the items in the tree. You'll see that both methods
DW> work on Windows but only copy-and-paste works on macOS, with the program
DW> crashing on the second drop using drag-and-drop. Also, if you alter the
DW> boolean value in the first line of the program, the code will use
DW> TextDataObject instead of CustomDataObject, and then both cut-and-paste and
DW> drag-and-drop will work on both platforms.
DW>
DW> I apologize that I don't have a C-based wxWidgets sample for you, but I was
DW> unable to get drag-and-drop working in C.

I understand that it's not simple to provide an example in C++, but
unfortunately it's also not simple to debug a wxPython example. But please
open a ticket on wxTrac with your example nevertheless, maybe somebody can
translate it to C++ later and, at the very least, this will ensure that we
can check if it's still broken later.

Thanks,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Robin Dunn]

I've done some digging on this. So far there are some indications that it may be related to NSAutoReleasePool, maybe something getting released too soon, or more than once? (See stack trace below.) After shuffling some things around in the test code I see some crashes related to wxDataFormat::m_format, with a crash in wxCFRelease. I found that using a global custom wxDataFormat instead of recreating it as needed seems to avoid the crashing.

I'll see if I can duplicate it in the C++ dnd sample, but if the clues above spark some ideas please don't wait for me. :-)

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread

0   com.apple.CoreFoundation      0x00007fff47c0889e _CFRelease + 1071

1   com.apple.CoreFoundation      0x00007fff47c398d0 cow_cleanup + 122

2   com.apple.CoreFoundation      0x00007fff47b336a8 -[__NSSetM dealloc] + 45

3   libobjc.A.dylib                0x00007fff7228d0c8 objc_object::sidetable_release(bool) + 268

4   com.apple.AppKit              0x00007fff45481aae -[_NSPasteboardTypeCache dealloc] + 64

5   libobjc.A.dylib                0x00007fff7228d0c8 objc_object::sidetable_release(bool) + 268

6   libobjc.A.dylib                0x00007fff7228847c (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 710

7   com.apple.CoreFoundation      0x00007fff47ad9d4a _CFAutoreleasePoolPop + 22

8   com.apple.Foundation          0x00007fff49d84792 -[NSAutoreleasePool drain] + 144

9   com.apple.AppKit              0x00007fff450f65f7 -[NSApplication run] + 810

10  libwx_osx_cocoau_core-3.1.5.0.0.dylib 0x00000001082e86db wxGUIEventLoop::OSXDoRun() + 171 (evtloop.mm:301)

11  libwx_baseu-3.1.5.0.0.dylib    0x00000001090a15c7 wxCFEventLoop::DoRun() + 39 (evtloop_cf.cpp:326)

12  libwx_baseu-3.1.5.0.0.dylib    0x0000000108f9a7d5 wxEventLoopBase::Run() + 229 (evtloopcmn.cpp:87)

13  libwx_baseu-3.1.5.0.0.dylib    0x0000000108f4e57d wxAppConsoleBase::MainLoop() + 189 (appbase.cpp:377)

14  _core.cpython-39-darwin.so    0x000000010738f8b8 wxPyApp::MainLoop() + 168 (sip_corewxPyApp.cpp:314)

15  _core.cpython-39-darwin.so    0x0000000107393f89 meth_wxPyApp_MainLoop(_object*, _object*) + 233 (sip_corewxPyApp.cpp:2035)

[Vadim Zeitlin]

On Thu, 7 Jan 2021 14:44:29 -0800 (PST) Robin Dunn wrote:

RD> I've done some digging on this. So far there are some indications that it
RD> may be related to NSAutoReleasePool, maybe something getting released too
RD> soon, or more than once?

Yes, definitely looks like this. Maybe building with ASAN could uncover
the culprit directly, but otherwise I'm afraid someone would still need to
debug it to discover where is the extra release coming from. At least I
definitely don't know this code well enough to tell it from just reading
it.

Sorry,

[Robin Dunn]

Vadim Zeitlin wrote on 1/7/21 4:02 PM:

> but otherwise I'm afraid someone would still need to
> debug it to discover where is the extra release coming from.

Oh, it looks like there is already a way to produce the bug in the dnd
sample. It's not exactly the same as my test case, a class is derived
from wxDataObject is used instead of using a wxCustomDataObject, but the
stack trace from the crash report is basically the same.

To reproduce in the dnd sample, open a couple new frames from the File
menu, use cmd-S in one of those frames to make a new shape, then drag it
to the other frame. This appears to work okay. Then try dragging it back
to the first window. The program should crash at that point. The crash
can also be triggered just by dragging and dropping the shape in the
same window more than once.

-- Robin

[Stefan Csomor]

Hi Robin

Am 08.01.21, 23:49 schrieb "wx-u...@googlegroups.com im Auftrag von Robin Dunn" <wx-u...@googlegroups.com im Auftrag von ro...@alldunn.com>:

Thanks a lot, reproducible, there's a zombie in the autorelease pool from the pasteboard, I'll try to nail that down ...

Best,

Stefan

[Stefan Csomor]

Hi

Vadim Zeitlin wrote on 1/7/21 4:02 PM:
> but otherwise I'm afraid someone would still need to
> debug it to discover where is the extra release coming from.

Oh, it looks like there is already a way to produce the bug in the dnd
sample. It's not exactly the same as my test case, a class is derived
from wxDataObject is used instead of using a wxCustomDataObject, but the
stack trace from the crash report is basically the same.

To reproduce in the dnd sample, open a couple new frames from the File
menu, use cmd-S in one of those frames to make a new shape, then drag it
to the other frame. This appears to work okay. Then try dragging it back
to the first window. The program should crash at that point. The crash
can also be triggered just by dragging and dropping the shape in the
same window more than once.

-- Robin

Thanks a lot, reproducible, there's a zombie in the autorelease pool from the pasteboard, I'll try to nail that down ...

Ok, it's the wxPasteBoardWriter writableTypesForPasteboard , right now I'm autoreleasing the types array, which is what other sample code does as well, but if I retain it, the problem goes away, so something in there is cause of trouble

Stay tuned,

Stefan

[Stefan Csomor]

Hi Robin

Am 09.01.21, 12:39 schrieb "Stefan Csomor" <wx-u...@googlegroups.com im Auftrag von cso...@advancedconcepts.ch>:

Could you please retest with #108b48f6 and test whether this also resolves the OP's problem ?

Thanks,

Stefan

[Robin Dunn]

Stefan Csomor wrote on 1/9/21 4:45 AM:
> Hi Robin

> Could you please retest with #108b48f6 and test whether this also resolves the OP's problem ?

Yes, that appears to have solved it. Thanks!

Robin