[wxCocoa] Crash regarding widget destruction.

[Деян Хаджиев]

Hi,

I have an application with a lot of dynamic content, which gets destroyed
and created on user actions. The application is working OK with wxCarbon
2.8.12 and wxCocoa 2.9.5, but when I tried with wxCocoa 3.0 and 3.1 the
application started crashing. I tried to find out what was causing the
crashes and I think that some destroyed object somehow is still being
accessed from the event loop for handling mouse events. I'm almost certain
of this because I tried to remove all Destroy() functions I call and the
crashes stopped. Prior to that I just tried to remove all dynamic handler
connections I make (with the Connect(..) function) but that didn't have any
effect.
I provide a stack frame from the crashes. Although the crash occurred at
different places the stack frame until the wxWidgetCocoaImpl::mouseEvent()
is always the same (including the mouseEvent()).

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x0000000100145d07 in wxWidgetCocoaImpl::mouseEvent () at dialog.h:72
72 virtual void ModalFinishedCallback(void* WXUNUSED(panel), int
WXUNUSED(returnCode)) {}
(gdb) bt
#0 0x0000000100145d07 in wxWidgetCocoaImpl::mouseEvent () at dialog.h:72
#1 0x00007fff81aad3a7 in -[NSWindow sendEvent:] ()
#2 0x000000010013138c in -[wxNSWindow sendEvent:] () at dialog.h:72
#3 0x00007fff819e2afa in -[NSApplication sendEvent:] ()
#4 0x000000010008e97a in -[wxNSApplication sendEvent:] () at event.h:1911
#5 0x00007fff819796de in -[NSApplication run] ()
#6 0x0000000100123cd8 in wxGUIEventLoop::OSXDoRun () at dialog.h:72
#7 0x000000010034241f in wxCFEventLoop::DoRun () at strconv.h:361
#8 0x00000001002ab991 in wxEventLoopBase::Run () at listbase.h:385
#9 0x0000000100274a57 in wxAppConsoleBase::MainLoop () at listbase.h:385
#10 0x00000001000de487 in wxApp::OnRun () at textctrl.h:681
#11 0x00000001002e44ad in wxEntry () at buffer.h:89

Is this a bug from 3.0 onwards or is it possible that I'm not doing
something right?

Best Regards,
Deyan Hadzhiev

[Vadim Zeitlin]

On Wed, 14 May 2014 05:55:58 -0700 (PDT) ДеяМ ХаЎжОев wrote:

ДХ> I have an application with a lot of dynamic content, which gets destroyed
ДХ> and created on user actions. The application is working OK with wxCarbon
ДХ> 2.8.12 and wxCocoa 2.9.5, but when I tried with wxCocoa 3.0 and 3.1 the
ДХ> application started crashing. I tried to find out what was causing the
ДХ> crashes and I think that some destroyed object somehow is still being
ДХ> accessed from the event loop for handling mouse events.

This is possible but we'd really need to have a small self-contained
example in order to debug and fix this.

ДХ> I provide a stack frame from the crashes.

This is useful but, unfortunately, not useful enough as you don't seem to
have debug information for this build. It would be nice if you could
rebuild it with debug info and check if this doesn't give additional
information.

Regards,
VZ

[Деян Хаджиев]

VZ> This is possible but we'd really need to have a small self-contained
VZ> example in order to debug and fix this.

I will try to write something as an example in the weekend, when I have
more time.
However I made more tests and the problem actually occurs only on OSX 10.6
Snow Leopard (even with wxCocoa 2.9.5), while wxCocoa doesn't crash on OSX
10.8 Mountain Lion. The 3.0 and 3.1 versions were tested only on 10.6, but
I think there will be no problem on 10.8 with them.

Regards
Deyan Hadzhiev

[Деян Хаджиев]

Hi,

I wrote an example program which I tested again on Windows, Linux and OSX,
and the problem was only on OSX (10.6 - Snow Leopard). The stack frame was
the same as before. I isolated the problem to the destruction of wxButtons
and that is why the example is as minimal as possible, only containing
several buttons created by user actions.

Best Regards
Deyan Hadzhiev

[Stefan Csomor]

Hi

Von: Деян Хаджиев <***@gmail.com>
Antworten an: "wx-***@googlegroups.com" <wx-***@googlegroups.com>
Datum: Montag, 19. Mai 2014 10:38
An: "wx-***@googlegroups.com" <wx-***@googlegroups.com>
Betreff: Re: [wxCocoa] Crash regarding widget destruction.

Post by Деян Хаджиев
I wrote an example program which I tested again on Windows, Linux and
OSX, and the problem was only on OSX (10.6 - Snow Leopard). The stack
frame was the same as before. I isolated the problem to the destruction
of wxButtons and that is why the example is as
minimal as possible, only containing several buttons created by user
actions.

the reason for crashing is the fact that you are destroying the instance
which had received the event (during mouse down) during the event handler
itself, and since wxOSX has to synthesize a mouse afterwards, this leads
to a problem. I've guarded the code against this now (r76579), but another
solution for these situations would be not to destroy it immediately, but
after this event has been handled via using
wxTheApp->ScheduleForDestruction

Best,

Stefan

[Деян Хаджиев]

Hi,

I tried the delayed destruction and it worked correctly, but I thought that
using the Destroy() function would handle such situations because of this
text (from the documentation) :
"Frames and dialogs are not destroyed immediately when this function is
called – they are added to a list of windows to be deleted on idle time,
when all the window's events have been processed."
Delayed destruction has one minor drawback - the button stays until an
Idle() loop and has to be hidden manually so it will not be seen until such
loop. I searched for function to force Idle() loop but couldn't find one.

Regards
Deyan Hadzhiev

[Stefan Csomor]

Hi

Post by Деян Хаджиев
I tried the delayed destruction and it worked correctly, but I thought
that using the Destroy() function would handle such situations because of
"Frames and dialogs are not destroyed immediately when this function is
called ­ they are added to a list of windows to be deleted on idle time,
when all the window's events have been processed."

yes, this is true for wxFrame and wxDialog, but the controls are destroyed
immediately

Post by Деян Хаджиев
Delayed destruction has one minor drawback - the button stays until an
Idle() loop and has to be hidden manually so it will not be seen until
such loop. I searched for function to force Idle() loop but couldn't find
one.

that's why I guarded the code, so things should work now, now, but if you
come across a similar situation where the fix isn't easy, then hiding it
first and adding to the delayed destruction list.

Best,

Stefan