diff options
Diffstat (limited to 'results/classifier/zero-shot/108/other/1802684')
| -rw-r--r-- | results/classifier/zero-shot/108/other/1802684 | 186 |
1 files changed, 186 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1802684 b/results/classifier/zero-shot/108/other/1802684 new file mode 100644 index 000000000..1b73f8133 --- /dev/null +++ b/results/classifier/zero-shot/108/other/1802684 @@ -0,0 +1,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. + + |