qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [Bug 974229] Re: qemu-kvm-1.0: segfault using vnc-console =


From: Thomas Huth
Subject: [Qemu-devel] [Bug 974229] Re: qemu-kvm-1.0: segfault using vnc-console => not threadsafe!
Date: Thu, 27 Oct 2016 11:37:07 -0000

The QEMU versions mentioned in this ticket are quite old already ... can
you still reproduce this with the latest version of QEMU? If so, please
also provide the exact command line parameters that you used to start
QEMU, and the steps you took afterwards to get to the crash? Thanks!

** Changed in: qemu
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/974229

Title:
  qemu-kvm-1.0: segfault using vnc-console => not threadsafe!

Status in QEMU:
  Incomplete
Status in qemu-kvm package in Ubuntu:
  Invalid

Bug description:
  after failure using qemu-kvm-0.14.1 I've tried v1.0, but there's a
  problem if compiled with vnc-thread-support:

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000000000 in ?? ()
  (gdb) bt
  #0  0x0000000000000000 in ?? ()
  #1  0x00007f3ac48ca10a in qemu_iohandler_poll (readfds=0x7fff12379ac0, 
writefds=0x7fff12379b40, xfds=0x7fff12379bc0, ret=3)
      at iohandler.c:124
  #2  0x00007f3ac4964387 in main_loop_wait (nonblocking=0) at main-loop.c:463
  #3  0x00007f3ac4958fb1 in main_loop () at 
/opt/workspace/oneiric64/qemu-kvm-1.0/vl.c:1482
  #4  0x00007f3ac495e1ec in main (argc=68, argv=0x7fff1237a088, 
envp=0x7fff1237a2b0)
      at /opt/workspace/oneiric64/qemu-kvm-1.0/vl.c:3523
  (gdb) up
  #1  0x00007f3ac48ca10a in qemu_iohandler_poll (readfds=0x7fff12379ac0, 
writefds=0x7fff12379b40, xfds=0x7fff12379bc0, ret=3)
      at iohandler.c:124
  124                   ioh->fd_write(ioh->opaque);

  (gdb) print *ioh
  $4 = {fd = 29, fd_read_poll = 0, fd_read = 0x7f3ac49de158 <vnc_client_read>, 
fd_write = 0, deleted = 0, 
    opaque = 0x7f3ac7978d50, next = {le_next = 0x7f3ac6add2e0, le_prev = 
0x7f3ac52bde90}}

  
  ok, how could that happen?
  loooking deeper at the code and backtraces shows, that iohandler.c:124 is 
called within the main-loop, while iohandler.c:77 is called within the 
vnc-thread-loop

  mmmh, but where the hell is the threadsafe-locking of the ioh-
  structure????

  I didn't found anything...

  the resetting in line 77 is called from vnc_client_write_plain(),
  where following code can be found:

  ===================
     if (vs->output.offset == 0) {
          qemu_set_fd_handler2(vs->csock, NULL, vnc_client_read, NULL, vs);
      }
  ===================

  why should the function-ptrs should be zeroed?

  further tracing shows, that the vnc-thread sometimes seems to exits
  normally and a new one is started (I haven't verified that), but this
  would be a reason for zeroing function-ptrs, which may point to code
  inside the thread, which will exit...

  but why should this be done? and why there's no threadsafe-
  modification of the structure?

  well: disabling vnc-thread at configure-state leads into a normal
  running machine, but threading would be nice here...

  so a quick fix could be, to drop the call above and make the vnc-thread 
staying for the whole session, but I don't know all mechanisms of vnc-support 
within kvm.
  but a better solution would be usage of clean locking-mechanisms

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/974229/+subscriptions



reply via email to

[Prev in Thread] Current Thread [Next in Thread]