Programs using wxWidgets-3.0 @3.0.0_2 fails to show GUI on OS X 10.9 Mavericks

[jxy (Xiao-Yong)]

The program, gnuplot @4.6.4_0+luaterm+pangocairo+wxwidgets-aquaterm-x11, hangs before showing any plot window.

I also tried a simple hello-world program, which compiles and links fine, but fail to show any GUI window upon starting from the commandline. Backtrace upon ctrl-C shows the following,

(lldb) bt
* thread #1: tid = 0xf2999, 0x00007fff8710fa1a libsystem_kernel.dylib`mach_msg_trap + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP
    frame #0: 0x00007fff8710fa1a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007fff8710ed18 libsystem_kernel.dylib`mach_msg + 64
    frame #2: 0x00007fff89b71315 CoreFoundation`__CFRunLoopServiceMachPort + 181
    frame #3: 0x00007fff89b70939 CoreFoundation`__CFRunLoopRun + 1161
    frame #4: 0x00007fff89b70275 CoreFoundation`CFRunLoopRunSpecific + 309
    frame #5: 0x00007fff88c2cf0d HIToolbox`RunCurrentEventLoopInMode + 226
    frame #6: 0x00007fff88c2ccb7 HIToolbox`ReceiveNextEventCommon + 479
    frame #7: 0x00007fff88c2cabc HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 65
    frame #8: 0x00007fff820ca28e AppKit`_DPSNextEvent + 1434
    frame #9: 0x00007fff820c98db AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
    frame #10: 0x00007fff820bd9cc AppKit`-[NSApplication run] + 553
    frame #11: 0x00000001004474b7 libwx_osx_cocoau_core-3.0.dylib`wxApp::CallOnInit() + 71
    frame #12: 0x0000000100a84c26 libwx_baseu-3.0.dylib`wxEntry(int&, wchar_t**) + 47
    frame #13: 0x0000000100000f86 hworld`main + 38
    frame #14: 0x00007fff845ab5fd libdyld.dylib`start + 1

[mojca (Mojca Miklavec)]

Can you please submit a ticket including the minimal hello world application to ​http://trac.wxwidgets.org?

(This is something that should be high priority to fix.)

[jxy (Xiao-Yong)]

hello-world using wxFrame

[jxy (Xiao-Yong)]

I'm not familiar with wxwidgets. I attached the minimal hello-world program, `hw_wx.cpp', here. If you can reproduce the issue, and you have an account on their bug tracker, please submit a ticket for me.

Thank you!

PS. compile the program with

clang++ hw_wx.cpp `wx-config --libs` `wx-config --cxxflags` -o hw_wx

[jxy (Xiao-Yong)]

I found a way to make the GUI window visible. A simple directory structure, or a so called app bundle works. After putting the binary, hw_wx, in a directory like the following

hw_wx.app
hw_wx.app/Contents
hw_wx.app/Contents/MacOS
hw_wx.app/Contents/MacOS/hw_wx

I can open the program without any issue.

But what can we do with a program like gnuplot?

[mojca (Mojca Miklavec)]

I don't plan to install 10.9 soon enough to be able to test before the release of wxWidgets 3.0.

Do all wxWidgets dependencies (that aren't bundled) have this problem or is it just gnuplot? For example, can you try if running

/opt/local/bin/usbprog-gui

from usbprog cause the same kind of crash?

Can you please also try if the following recipe ​http://wiki.wxwidgets.org/WxMac_Issues#My_app_can.27t_be_brought_to_the_front.21 for your minimal example does any difference (please don't bundle the app, just add this code).

And ... oh, wait! I'm running 10.7. Gnuplot doesn't crash, but it doesn't display anything either. It seems that we need to figure out when this problem was introduced.

[jxy (Xiao-Yong)]

Minimum working code.

[jxy (Xiao-Yong)]

Patch for gnuplot-4.6.4

[jxy (Xiao-Yong)]

I attached patch-wxt-mavericks.diff​ for gnuplot. Works for me. Please check. The deprecated procedure SetFrontProcess brings the window to the front.

If you have account for gnuplot bug tracker, please propagate it upstream.

[mojca (Mojca Miklavec)]

I'm a bit swamped in time to do any decent testing. While I can fix gnuplot in MacPorts, I still believe that this is a problem in wxWidgets, not a problem in all the other software.

Checking which commit caused the problem should be easy enough (just doing bisection between 2.9.5 and 3.0.0-rc1) and in addition to that I strongly suspect that ​http://trac.wxwidgets.org/changeset/74703 could be a serious candidate to blame. Do you have time/motivation to check if reversing that change makes any difference in unmodified gnuplot (or to check which commit between the two releases is to blame)?

Plus, I just noticed that that particular commit might be problematic for other reasons. It checks for WXOSX instead of WXGTK. And it only removes code from carbon, but not from cocoa. So I need to file a ticket to fix that too.

[mojca (Mojca Miklavec)]

See also ​http://comments.gmane.org/gmane.comp.lib.wxwidgets.devel/151720

[mojca (Mojca Miklavec)]

The following needs some testing: ​http://trac.wxwidgets.org/changeset/75142

[mojca (Mojca Miklavec)]

Can you please test the patch in r113110? I forgot to reference the ticket and I didn't include it into the port yet, but I would like to know if it solves the problem on 10.9. I'm not yet sure, but there is a chance that wxWidgets dependencies need to be revbumped after this change.

[mojca (Mojca Miklavec)]

Did you manage to test the patch on 10.9?

[jxy (Xiao-Yong)]

Thanks, @mojca, for your effort. The new patch works perfectly. I guess we can close this ticket now.

[mojca (Mojca Miklavec)]

The fix is in r113320. The upstream is only partially fixed: it's fixed in trunk, but not entirely in 3.0.0.