1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
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.
|