Re: [Qemu-devel] Crash when using -daemonize

[Christian Borntraeger <borntraeger@de.ibm.com>]

Am 09.03.2015 um 22:03 schrieb Stefan Berger:
> Since an upgrade to Fedora 21, I get crashes with QEMU when using -daemonize. I noticed this since libvirt could not QMP probe QEMU.
> 
> This is the command line used:
> 
> x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -M none -pidfile /tmp/foo -daemonize
> 
> Here's the backtrace from the coredump:
> 
> #0  0x00007fe653d5c8d7 in __GI_raise (sig=sig@entry=6)
>     at ../sysdeps/unix/sysv/linux/raise.c:55
> #1  0x00007fe653d5e53a in __GI_abort () at abort.c:89
> #2  0x00007fe658c4cb80 in error_exit (err=<optimized out>,
>     msg=msg@entry=0x7fe658f58580 <__func__.6036> "qemu_mutex_unlock")
>     at util/qemu-thread-posix.c:48
> #3  0x00007fe658edcab0 in qemu_mutex_unlock (
>     mutex=mutex@entry=0x7fe6593a01c0 <qemu_global_mutex>)
>     at util/qemu-thread-posix.c:93
> #4  0x00007fe658c7a96c in qemu_mutex_unlock_iothread ()
>     at /root/qemu/qemu-git.pt/cpus.c:1137
> #5  0x00007fe658e7695f in os_host_main_loop_wait (timeout=-1)
>     at main-loop.c:234
> #6  main_loop_wait (nonblocking=<optimized out>) at main-loop.c:494
> #7  0x00007fe658c4e82e in main_loop () at vl.c:1795
> #8  main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>)
>     at vl.c:4354
> 
> I am using today's tip of the QEMU git tree, but I don't think that's the actual problem.

I think it is. 
Paolo has posted a quick fix in the thread of "vl: take iothread lock very early".

Can you verify? 

Paolo, what is the status of this fix?



diff --git a/vl.c b/vl.c
index e1ffd0a..af61835 100644
--- a/vl.c
+++ b/vl.c
@@ -3759,7 +3759,9 @@ int main(int argc, char **argv, char **envp)

     loc_set_none();

+    qemu_mutex_unlock_iothread();
     os_daemonize();
+    qemu_mutex_lock_iothread();

     if (qemu_init_main_loop(&main_loop_err)) {
         error_report_err(main_loop_err);

> 
> Anyone have an idea? I reinstalled glibc, but that doesn't seem to solve what looks like a mutex problem.
> 
>    Stefan
> 
>