Am 09.03.2011 um 11:20 schrieb Jan Kiszka: > On 2011-03-09 11:16, Peter Lieven wrote: >> >> Am 09.03.2011 um 08:37 schrieb Jan Kiszka: >> >>> On 2011-03-08 23:53, Peter Lieven wrote: >>>> Hi, >>>> >>>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfault. i have seen similar crash already in 0.13.0, but had no time to debug. >>>> my guess is that this segfault is related to the threaded vnc server which was introduced in qemu 0.13.0. the bug is only triggerable if a vnc >>>> client is attached. it might also be connected to a resolution change in the guest. i have a backtrace attached. the debugger is still running if someone >>>> needs more output >>>> >>> >>> ... >>> >>>> Thread 1 (Thread 0x7ffff7ff0700 (LWP 29038)): >>>> #0 0x0000000000000000 in ?? () >>>> No symbol table info available. >>>> #1 0x000000000041d669 in main_loop_wait (nonblocking=0) >>>> at /usr/src/qemu-kvm-0.14.0/vl.c:1388 >>> >>> So we are calling a IOHandlerRecord::fd_write handler that is NULL. >>> Looking at qemu_set_fd_handler2, this may happen if that function is >>> called for an existing io-handler entry with non-NULL write handler, >>> passing a NULL write and a non-NULL read handler. And all this without >>> the global mutex held. >>> >>> And there are actually calls in vnc_client_write_plain and >>> vnc_client_write_locked (in contrast to vnc_write) that may generate >>> this pattern. It's probably worth validating that the iothread lock is >>> always held when qemu_set_fd_handler2 is invoked to confirm this race >>> theory, adding something like >>> >>> assert(pthread_mutex_trylock(&qemu_mutex) != 0); >>> (that's for qemu-kvm only) >> >> qemu_mutex doesn't exists (anymore). i can only find qemu_global_mutex and qemu_fair_mutex. > > In qemu-kvm, qemu-kvm.c contains that lock. In upstream, it's > qemu_global_mutex, but you will have to enable --enable-io-thread and > export it. qemu-kvm doesn't compile with --enable-io-thread LINK x86_64-softmmu/qemu-system-x86_64 kvm-all.o: In function `qemu_mutex_unlock_iothread': /usr/src/qemu-kvm-0.14.0/qemu-kvm.c:1735: multiple definition of `qemu_mutex_unlock_iothread' cpus.o:/usr/src/qemu-kvm-0.14.0/cpus.c:752: first defined here kvm-all.o: In function `qemu_mutex_lock_iothread': /usr/src/qemu-kvm-0.14.0/qemu-kvm.c:1742: multiple definition of `qemu_mutex_lock_iothread' cpus.o:/usr/src/qemu-kvm-0.14.0/cpus.c:738: first defined here ../compatfd.o: In function `qemu_signalfd': /usr/src/qemu-kvm-0.14.0/compatfd.c:105: multiple definition of `qemu_signalfd' ../compatfd.o:/usr/src/qemu-kvm-0.14.0/compatfd.c:105: first defined here collect2: ld returned 1 exit status make[1]: *** [qemu-system-x86_64] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 > >> >> i try with qemu_global_mutex now. if thats not correct please tell. > > I think we knokw know the call path, so you could also wait for Corentin > to send a patch and test that one. will do as soon as i get it ;-) > > Jan > Peter -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
