#162 Crash on exit on Mac OS X

[Mojca Miklavec]

On Mac OS X 10.7, x86_64, almost the latest SVN checkout (from 1st May 2015), compiled against wxWidgets 3.0.

When I open Code::Blocks and exit it (CodeBlocks -> Exit CodeBlocks; without doing anything else), I get the following wxWidgets Debug Alert:

../src/common/wincmn.cpp(478): assert "GetEventHandler() == this" failed in ~wxWindowBase(): any pushed event handlers must have been removed

Call stack:
[00] wxWindow::~wxWindow()                   
[01] wxTopLevelWindowBase::~wxTopLevelWindowBase() 
[02] MainFrame::~MainFrame()                 
[03] wxAppBase::CleanUp()                    
[04] wxApp::CleanUp()                        
[05] wxEntryCleanup()                        
[06] wxUninitialize()                        
[07] wxEntry(int&, wchar_t**)                
[08] main                                    
[09] start                                   
[10] 0x00000002                              

Do you want to stop the program?
You can also choose [Cancel] to suppress further warnings.

If I pick "No", the program exits gracefully. If I pick "Yes", the program crashes. Crash log attached.

This is not a showstopper as it only happens at the very end of program execution, but it might be worth looking into at some point. (There might be other similar crashes during program execution.)

[Teodor Petrov]

Probably this issue is fixed in the latest night builds, can you please try and report if it still happens? I think we fixed something similar on linux.

[Mojca Miklavec]

I can try your binaries if that makes any difference. But I just compiled Code::Blocks from the latest commit in branches-16.xx and the problem (the crash) is still there.

[Teodor Petrov]

Do you have any plugins installed and enabled? Can you disable them?

[Mojca Miklavec]

Do you mean plugins that are installed independently or those that are part of the default build? If the first ones, no, I didn't install any plugins. If you mean those that come as part of the build, I built with --with-contrib-plugins=all,-FileManager. I can try to rebuild without them.

(Manage plugins doesn't show any plugins as installed.)

[Teodor Petrov]

Yes, I'm talking about the latter case. Most of the code in C::B is stored in plugins, so you don't have to rebuild either you can remove the .so/.dylib files for the plugins or use the plugins -> manage window to disable them (but they are still loaded even if disabled).

[Mojca Miklavec]

I tried sudo mv /opt/local/lib/codeblocks/plugins /tmp and I get the same crash after that.

[Teodor Petrov]

Ok, can you try to debug codeblocks with debugger and enable catching throw statements? In gdb this is done with the "catch throw" command. If this is in another assert please post the backtrace.

[Mojca Miklavec]

I tried catch throw, but I see more or less the same info. The same assert pops up, but then gdb waits (that's where I inserted a backtrace) and I have to use cont at some point; and I don't get a window asking me to report the crash to Apple:

Initializing plugins...
Reading symbols for shared libraries . done
Reading symbols for shared libraries ......... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries ... done
Reading symbols for shared libraries . done
../src/common/wincmn.cpp(478): assert "GetEventHandler() == this" failed in ~wxWindowBase(): any pushed event handlers must have been removed
Collecting stack trace information, please wait...
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007fff8a15582a in __kill ()
(gdb) backtrace
#0  0x00007fff8a15582a in __kill ()
#1  0x000000010115f258 in wxGUIAppTraitsBase::ShowAssertDialog ()
#2  0x00000001016d05bf in ShowAssertDialog ()
#3  0x00000001016d0119 in wxAppConsoleBase::OnAssertFailure ()
#4  0x00000001016d0f96 in wxDefaultAssertHandler ()
#5  0x00000001016ce8be in wxOnAssert ()
#6  0x000000010124f65e in wxWindowBase::~wxWindowBase ()
#7  0x000000010109e2aa in wxWindow::~wxWindow ()
#8  0x0000000101246de4 in wxTopLevelWindowBase::~wxTopLevelWindowBase ()
#9  0x000000010009c54b in MainFrame::~MainFrame ()
#10 0x000000010115ecaf in wxAppBase::CleanUp ()
#11 0x00000001010db32c in wxApp::CleanUp ()
#12 0x00000001017405b0 in wxEntryCleanup ()
#13 0x000000010174083d in wxUninitialize ()
#14 0x0000000101740699 in wxEntry ()
#15 0x0000000100007380 in main ()
(gdb) n
Single stepping until exit from function __kill, 
which has no line number information.
0x000000010115f258 in wxGUIAppTraitsBase::ShowAssertDialog ()
(gdb) 
Single stepping until exit from function _ZN18wxGUIAppTraitsBase16ShowAssertDialogERK8wxString, 
which has no line number information.
0x00000001016d05bf in ShowAssertDialog ()
(gdb) 
Single stepping until exit from function _ZL16ShowAssertDialogRK8wxStringiS1_S1_S1_P11wxAppTraits, 
which has no line number information.
0x00000001016d0119 in wxAppConsoleBase::OnAssertFailure ()
(gdb) 
Single stepping until exit from function _ZN16wxAppConsoleBase15OnAssertFailureEPKwiS1_S1_S1_, 
which has no line number information.
0x00000001016d0f96 in wxDefaultAssertHandler ()
(gdb) 

I could try building with debug symbols (or rather remove all the "strip" commands that someone has put in the package for CB – which is what I use instead of building manually).

[Teodor Petrov]

I don't think it will help. This need someone to debug it...

[Mojca Miklavec]

But if you want to see more examples, here's what I get when I attempt printing (after Print error: could not start printing):

../src/osx/cocoa/utils.mm(522): assert "gs_wxBusyCursorCount > 0" failed in wxEndBusyCursor(): no matching wxBeginBusyCursor() for wxEndBusyCursor()

Call stack:
[00] wxMacPrinter::Print(wxWindow*, wxPrintout*, bool) 
[01] wxPrinter::Print(wxWindow*, wxPrintout*, bool) 
[02] cbEditor::Print(bool, PrintColourMode, bool) 
[03] MainFrame::OnFilePrint(wxCommandEvent&) 
[04] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) 
[05] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) 
[06] wxEvtHandler::TryHereOnly(wxEvent&)     
[07] wxEvtHandler::ProcessEvent(wxEvent&)    
[08] wxEvtHandler::DoTryChain(wxEvent&)      
[09] wxEvtHandler::ProcessEventLocally(wxEvent&) 
[10] wxEvtHandler::ProcessEvent(wxEvent&)    
[11] wxWindowBase::TryAfter(wxEvent&)        
[12] wxEvtHandler::ProcessEvent(wxEvent&)    
[13] wxEvtHandler::SafelyProcessEvent(wxEvent&) 
[14] wxWindowBase::HandleWindowEvent(wxEvent&) const 
[15] wxMenuBase::SendEvent(int, int)         
[16] wxMenu::HandleCommandProcess(wxMenuItem*, wxWindow*) 
[17] -[wxNSMenuItem clickedAction:]          
[18] -[NSObject performSelector:withObject:] 
[19] -[NSApplication sendAction:to:from:]    
[20] -[NSMenuItem _corePerformAction]        
Do you want to stop the program?
You can also choose [Cancel] to suppress further warnings.

(I get the PDF though.)

[Teodor Petrov]

As far as I see we don't call wxEndBusyCursor anywhere in the printing code, so this is most probably a wxwidgets issue. Can you reproduce this as the first thing after starting C::B?

[Mojca Miklavec]

The error from wincmn.cpp also comes from wxWidgets, not from CB. For the printing issue I need to start printing a document and this is always reproducible. (Please note that I'm not using CB for any work, I merely happened to be involved in reporting problems after doing the transition from wxWidgets 2.8 to 3.0 in a package manager. The program still seems to have too many issues on Mac to provide a smooth user experience though, but at least it compiles.)

[Teodor Petrov]

The wincmn.cpp error is probably a bug in cb. It seems that we're calling PushEventHandler but we're not calling RemoveEventHandler at exit. Unfortunately this problem doesn't happen on linux and I cannot debug it right a way. If you're interested you can add printf statements before every pusheventhandler to print the address of the pushed event handler and then compare the address of the push with the address returned in the assert. This will lead you to the handler that needs to be removed. I guess you'll have to repeat this several times.

About the printing: Can you try this in a printing sample in the wxlibrary? I think it will have the same problem.

[Mojca Miklavec]

(Unrelated: am I the only one constantly experiencing loss of data when replying to posts in this tracker?)

With the example on https://wiki.wxwidgets.org/Printing I don't get any crash. I get:

2016-01-19 23:51:48.873 a[52363:1303] Could not find image named 'LayoutDirection1.png'.
2016-01-19 23:51:52.769 a[52363:1303] Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
2016-01-19 23:51:52.770 a[52363:1303] Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
beginning to print document, from page 1 to 9999
printing page 1
printable area : (0, 0) to (534, 699)
...

but it works. I don't know which example you wanted me to try and I also don't know what to put inside printf for PushEventHandler. Which addresses?

[Teodor Petrov]

The PushEventHandler a pointer parameter - print it then compare the address in the assert with the printed values.

About printing: wxWidgets has a folder samples that has many small applications, probably there is one doing printing try to reproduce the assert using one of these.

[Miguel Gimenez]

Closed; the ticket is six years old, the MacOS executable has changed a lot and there are no recent reports about this issue.