[Qemu-devel] Re: segmentation fault in qemu-kvm-0.14.0

[Peter Lieven]

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