other: 0.852
graphic: 0.821
permissions: 0.777
KVM: 0.757
semantic: 0.744
debug: 0.731
vnc: 0.729
device: 0.722
PID: 0.665
performance: 0.639
socket: 0.610
boot: 0.570
network: 0.430
files: 0.331

QEMU gui crashes on macOS Mojave

QEMU release 3.0.0 as well as a recent head build

/usr/local/Cellar/qemu/HEAD-03c1ca1 (147 files, 257.2MB)
  Built from source on 2018-11-06 at 13:41:32 with: --with-gtk+3 --with-sdl2 --with-libusb
/usr/local/Cellar/qemu/3.0.0 (137 files, 261.6MB) *
  Poured from bottle on 2018-11-10 at 22:58:32 with: --with-gtk+3 --with-libusb --with-sdl2

Crashes when attempting to use any gui interface (tried SDL and default Cocoa):

2018-11-10 22:58:41.799 qemu-system-aarch64[42982:1102466] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff3ea96ecd __exceptionPreprocess + 256
	1   libobjc.A.dylib                     0x00007fff6ab49720 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff3eab095d -[NSException raise] + 9
	3   AppKit                              0x00007fff3bfb13fa -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 324
	4   AppKit                              0x00007fff3bfb6850 -[NSView setFrameSize:] + 2082
	5   AppKit                              0x00007fff3c02747d -[NSVisualEffectView setFrameSize:] + 171
	6   AppKit                              0x00007fff3c0811b1 -[NSTitlebarView setFrameSize:] + 84
	7   AppKit                              0x00007fff3bfb5859 -[NSView setFrame:] + 478
	8   AppKit                              0x00007fff3c081154 -[NSTitlebarView resizeWithOldSuperviewSize:] + 100
	9   AppKit                              0x00007fff3bfbc95e -[NSView resizeSubviewsWithOldSize:] + 502
	10  AppKit                              0x00007fff3bfb66d9 -[NSView setFrameSize:] + 1707
	11  AppKit                              0x00007fff3c9773c0 -[NSTitlebarContainerView setFrameSize:] + 142
	12  AppKit                              0x00007fff3bfb5859 -[NSView setFrame:] + 478
	13  AppKit                              0x00007fff3bfbcdb5 -[NSView resizeWithOldSuperviewSize:] + 776
	14  AppKit                              0x00007fff3bfbc95e -[NSView resizeSubviewsWithOldSize:] + 502
	15  AppKit                              0x00007fff3bfb66d9 -[NSView setFrameSize:] + 1707
	16  AppKit                              0x00007fff3c024570 -[NSThemeFrame setFrameSize:] + 495
	17  AppKit                              0x00007fff3c011223 -[NSWindow _setFrame:updateBorderViewSize:] + 966
	18  AppKit                              0x00007fff3c010b46 -[NSWindow _oldPlaceWindow:] + 547
	19  AppKit                              0x00007fff3c010151 -[NSWindow _setFrameCommon:display:stashSize:] + 3006
	20  AppKit                              0x00007fff3c00f57d -[NSWindow _setFrame:display:allowImplicitAnimation:stashSize:] + 192
	21  AppKit                              0x00007fff3c019ff8 -[NSWindow setFrame:display:animate:] + 567
	22  qemu-system-aarch64                 0x000000010b7b2abf qemu-system-aarch64 + 3668671
	23  qemu-system-aarch64                 0x000000010b7b6356 qemu-system-aarch64 + 3683158
	24  qemu-system-aarch64                 0x000000010b7ad836 qemu-system-aarch64 + 3647542
	25  qemu-system-aarch64                 0x000000010b4ce769 qemu-system-aarch64 + 636777
	26  qemu-system-aarch64                 0x000000010b487c24 qemu-system-aarch64 + 347172
	27  qemu-system-aarch64                 0x000000010b487a15 qemu-system-aarch64 + 346645
	28  qemu-system-aarch64                 0x000000010b4878f1 qemu-system-aarch64 + 346353
	29  qemu-system-aarch64                 0x000000010b4414aa qemu-system-aarch64 + 58538
	30  qemu-system-aarch64                 0x000000010b4f78c3 qemu-system-aarch64 + 805059
	31  qemu-system-aarch64                 0x000000010b487c24 qemu-system-aarch64 + 347172
	32  qemu-system-aarch64                 0x000000010b487a15 qemu-system-aarch64 + 346645
	33  qemu-system-aarch64                 0x000000010b4878f1 qemu-system-aarch64 + 346353
	34  qemu-system-aarch64                 0x000000010b4b8f57 qemu-system-aarch64 + 548695
	35  qemu-system-aarch64                 0x000000010b49c3af qemu-system-aarch64 + 431023
	36  ???                                 0x00000001117891f3 0x0 + 4588081651
)
libc++abi.dylib: terminating with uncaught exception of type NSException
fish: 'qemu-system-aarch64 -M raspi3 -…' terminated by signal SIGABRT (Abort)


macOS Mojave 10.14.2 Beta (18C38b)
Qemu in the same configuration used to work in High Sierra, started crashing only after upgrade to Mojave.

Command line:
`qemu-system-aarch64 -M raspi3 -d in_asm -serial stdio -kernel $1.bin`

Thanks for the bug report. It looks like Mojave is pickier about apps not calling various GUI update functions from the "wrong" thread. We probably need to figure out how to dispatch those to the main thread instead of whatever thread we were on. Unfortunately we don't really have anybody in QEMU upstream who knows much about OSX or its GUI, and I suspect we don't have anybody with Mojave (my system is still High Sierra and I don't plan to upgrade it for a while); help and patches appreciated from anybody who does...


I'll see if I have some time this weekend to dig into qemu Cocoa layer.

The code for the cocoa stuff is in ui/cocoa.m. Quick notes on structure:

 * there is a weird thing where cocoa.m provides its own main(), and arranges that the function which is main() for every other UI is renamed qemu_main() and called later (I'd like to get rid of that one day if we could, it's just weird)
 * cocoa_display_init() is the "initialize the display" entry point -- this will always be called from on the main thread (strictly, from whichever thread OSX calls our applicationDidFinishLaunching callback on, but I assume that's the main thread)
 * the runtime entry points into the cocoa UI code are just the functions in the DisplayChangeListener struct: cocoa_update(), cocoa_switch() and cocoa_refresh()

Arranging for the last 3 to schedule their operation onto the main thread is probably what's needed. Things I don't know:

 * should this "run thing on main thread" be synchronous or asynchronous? (sync is probably safest)
 * what's the right OSX API to do this?
 * how can we most cleanly do this in a way that still works on OSX 10.6 (the oldest we currently support)? (I suspect we'll need ifdefs and fall back to "just run on this thread" on older versions)


I made DisplayChangeListener callbacks dispatch updates to the main thread and it stopped crashing. However, pure Cocoa UI seems non-functional - I can't focus the window, I don't see any application menus, and the fb does not update.

I'm looking at making SDL code thread-safe the same way - because it also calls into Cocoa, and crashes in the same way.

What is the process for submitting PRs to qemu? I'm used to github but I see you use your own git hosting.

Thanks for having a look at this. The cocoa UI does work for me on High Sierra, for what that's worth.

https://wiki.qemu.org/Contribute/SubmitAPatch has our patch submission process.

My feeling on SDL is that this would be a bug to fix in upstream SDL, assuming we're not breaking any "which thread" requirements in the SDL API. It's the job of the SDL abstraction layer to work around host-OS-specific issues. (I didn't realize that the SDL display code worked on OSX QEMU, though -- the only one I've ever used is the Cocoa one, and I would expect anything else to interact weirdly with the way the cocoa UI frontend assumes it's in control.)



> On Nov 11, 2018, at 2:39 AM, <email address hidden> wrote:
> 
> Thanks for the bug report. It looks like Mojave is pickier about apps
> not calling various GUI update functions from the "wrong" thread. We
> probably need to figure out how to dispatch those to the main thread
> instead of whatever thread we were on. Unfortunately we don't really
> have anybody in QEMU upstream who knows much about OSX or its GUI, and I
> suspect we don't have anybody with Mojave (my system is still High
> Sierra and I don't plan to upgrade it for a while); help and patches
> appreciated from anybody who does...

>  	21  AppKit                              0x00007fff3c019ff8 -[NSWindow setFrame:display:animate:] + 567

I would use the [performSelectorOnMainThread: withObject: waitUntilDone:] method to fix this problem. It should go here in the call stack. I would make the patch myself but I don't know where this call takes place in qemu-system-aarch64.

>  	22  qemu-system-aarch64                 0x000000010b7b2abf qemu-system-aarch64 + 3668671



Ok I think I found places where code was invalid in Cocoa and fixed it. I can see qemu running my kernel and all interface is responsive. I also believe it should be working on as old as macOS 10.6 machines as well - do you have some CI machines with these versions to test? I don't.

For SDL i didn't look into the details yet. Will try to set up a reproducible case for SDL2 folks over the week.

Will send the patches to mailing list as suggested.

Patches emailed.

Changes reviewable in a decent web-ui here - https://github.com/qemu/qemu/compare/master...berkus:mojave-cocoa-fix?expand=1

http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg01941.html thread

Could I ask you to make a debug build of QEMU (configure with --enable-debug) of the current git master, and recreate the backtrace that you quoted in your report, but with the debug symbols? I'm trying to figure out exactly what we're doing on what threads right now, and it would be very helpful to find out what threads are doing what. Specifically, could you do this with the cocoa UI (not SDL) and give a backtrace of all threads at the point where the assert hits, please?


Ok, will do.


I've had a report from another user that the OSX GUI code works fine for them on Mojave, so maybe the problem you're running into here is more specific than just "doesn't work on this OS". That backtrace might help in narrowing down what is different for you.


Can you try to build it without SDL/GTK support? I'm not having any issues with Cocoa display.

I tried building the latest git master and get weird results - it seems to
work, at least not crashing with any checks that were there before (built
using plain cocoa ui, no sdl or gtk). I will check back at the original
master that caused me issues and report.
On Thu, 29 Nov 2018 at 16:46, Peter Maydell <email address hidden>
wrote:

> I've had a report from another user that the OSX GUI code works fine for
> them on Mojave, so maybe the problem you're running into here is more
> specific than just "doesn't work on this OS". That backtrace might help
> in narrowing down what is different for you.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1802684
>
> Title:
>   QEMU gui crashes on macOS Mojave
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1802684/+subscriptions
>


I've tried to run two x86 guests with Cocoa display on 3.1 rc3, the GUI doesn't crash. I've tried to change screen resolution on openSUSE 15, it also works without an issue.

My command line is:
./x86_64-softmmu/qemu-system-x86_64 -accel hvf -cpu host -hda /path/to/disk -m MEMORY

https://<email address hidden>/ is an RFC patchset which tries to address all the locking issues and make the main thread run only the Cocoa UI event loop, with no blocking operations in UI event callbacks. It's RFC because (as noted in the last two comments) it's not clear any more if it's a necessary refactoring.

We think we have shaken all the bugs out of the patchset which overhauls the Cocoa UI, so the crashes on OSX Mojave should be fixed in QEMU git master; these will be in QEMU 4.0.