Testing on other systems reveals that this is solid on Slackware14.1, with it's associated libraries. Interestingly, the more heavily the machine is loaded, the further the emulator runs prior to hanging . . . The 1.7.1 code, compiled on an older Slackware (loosely based on 12, but has evolved, but generally older libs) appears to work. I have changed out most libs that seem apparent - gtk+, vte, and a few others, as well as compiling with slirp and aio disabled, as well as not using gthreads, to no avail. This appears to be a race between the gtk window thread, and qemu, but the qemu source is so large, that I have not yet been able to find that area of the code to be able to debug deeper.
Help! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1320030 Title: Qemu 2.0.0 with display=gtk hangs Status in QEMU: New Bug description: When qemu 2.0.0 is started, compiled with gtk, communications between the emulator process and the gtk "wrapper" window hang, and the emulator hangs typically before the bios finishes initializing, and if boot menu=on is selected, even if it gets to this point, keyboard input is not accepted to the emulator process. Switching to the session console in the window header yeilds a fully functional console with zero input issues, indicating that the overall process is getting keyboard data, just not cleanly passing it to the emulator. A "system_reset" in the console will typically result in a bit more execution of the emulator, and then a subsequent hang at a later point. When the hang occurs, CPU useage pegs at 100%, and when I strace the process, I get typically 20,000 lines in the trace in about 2 seconds, 90% of which is repetitive: read(5, 0x7fff965c4df0, 16) = -1 EAGAIN (Resource temporarily unavai lable) write(5, "\1\0\0\0\0\0\0\0", 8) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 read(9, "\1\0\0\0\0\0\0\0", 512) = 8 write(4, "\1\0\0\0\0\0\0\0", 8) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily un available) ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11, eve nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17, events=POLL IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}], 8, {0, 0}, NULL, 8) = 2 ([{f d=5, revents=POLLIN}, {fd=4, revents=POLLIN}], left {0, 0}) write(5, "\1\0\0\0\0\0\0\0", 8) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 read(4, "\1\0\0\0\0\0\0\0", 512) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily un available) futex(0x7f562ce32e40, FUTEX_WAKE_PRIVATE, 1) = 1 ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11, eve nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17, events=POLL IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}, {fd=14, events=POLLIN}, {fd=1 6, events=POLLIN}, {fd=12, events=POLLIN}], 11, {0, 20060537}, NULL, 8) = 1 ([{f d=5, revents=POLLIN}], left {0, 20056426}) read(5, "\10\0\0\0\0\0\0\0", 16) = 8 recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily un available) futex(0x7f562ce32e40, FUTEX_WAKE_PRIVATE, 1) = 1 ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11, eve nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17, events=POLL IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}, {fd=14, events=POLLIN}, {fd=1 6, events=POLLIN}, {fd=12, events=POLLIN}], 11, {0, 19878122}, NULL, 8) = 1 ([{f d=9, revents=POLLIN}], left {0, 19672563}) futex(0x7f562ce32e40, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource tempora rily unavailable) read(5, 0x7fff965c4df0, 16) = -1 EAGAIN (Resource temporarily unavai lable) write(5, "\1\0\0\0\0\0\0\0", 8) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 read(9, "\1\0\0\0\0\0\0\0", 512) = 8 write(4, "\1\0\0\0\0\0\0\0", 8) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily un available) ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11, eve nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17, events=POLL IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}], 8, {0, 0}, NULL, 8) = 2 ([{f d=5, revents=POLLIN}, {fd=4, revents=POLLIN}], left {0, 0}) write(5, "\1\0\0\0\0\0\0\0", 8) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 read(4, "\1\0\0\0\0\0\0\0", 512) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 write(5, "\1\0\0\0\0\0\0\0", 8) = 8 recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily un available) futex(0x7f562ce32e40, FUTEX_WAKE_PRIVATE, 1) = 1 ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11, eve nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17, events=POLL IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}, {fd=14, events=POLLIN}, {fd=1 6, events=POLLIN}, {fd=12, events=POLLIN}], 11, {0, 18960120}, NULL, 8) = 1 ([{f d=5, revents=POLLIN}], left {0, 18956018}) read(5, "\10\0\0\0\0\0\0\0", 16) = 8 recvfrom(11, 0x7f562e697c14, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily un available) futex(0x7f562ce32e40, FUTEX_WAKE_PRIVATE, 1) = 1 ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=11, eve nts=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=17, events=POLL IN}, {fd=9, events=POLLIN}, {fd=4, events=POLLIN}, {fd=14, events=POLLIN}, {fd=1 6, events=POLLIN}, {fd=12, events=POLLIN}], 11, {0, 18778228}, NULL, 8) = 1 ([{f d=9, revents=POLLIN}], left {0, 18580700}) The host system has an average load as of this test of .38, and is 8 2.33GHz Xeon cores, and 8GB RAM with a 3.10.17 kernel, and nowhere near swapping . . . (Distro is slackware 14.1, FWIW) The above was generated with the command: strace qemu-system-x86_64 linux-0.2.img -cpu Westmere -k en-us -machine accel=kvm This occurs with any cpu, with or without the "-k" (I had seen some reports that some probs in the GTK build were resolved by this option - no joy here) and with and without the "accell=kvm" (again tried based on other found bugs/solutions.). Thus: strace qemu-system-x86_64 linux0.2.img Behaves identically, and disabling serial and parallel also has zero impact. If I run with "-display=sdl" then the image boots perfects, as is also the case if I build qemu with --disable-gtk. This situation is identical on a remote display, and also in 1.7.1. No variation in current git build, uploaded 05/15/2014, 18:58 CST . . . To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1320030/+subscriptions
