aboutsummaryrefslogtreecommitdiff
path: root/oslib-win32.c
diff options
context:
space:
mode:
authorLuiz Capitulino <lcapitulino@redhat.com>2011-10-28 14:59:52 -0200
committerAnthony Liguori <aliguori@us.ibm.com>2011-11-01 11:50:12 -0500
commit1fdc11c36971e0d4eeb2ce817f7e520b2028c2f2 (patch)
tree37dee76f6f6bec93f7be3b90ae580c56412d90e7 /oslib-win32.c
parent4f39d27fe4e8109ba9eb2983b27675f2ca6d3ecb (diff)
Fix segfault on migration completion
A simple migration reproduces it: 1. Start the source VM with: # qemu [...] -S 2. Start the destination VM with: # qemu <source VM cmd-line> -incoming tcp:0:4444 3. In the source VM: (qemu) migrate -d tcp:0:4444 4. The source VM will segfault as soon as migration completes (might not happen in the first try) What is happening here is that qemu_file_put_notify() can end up closing 's->file' (in which case it's also set to NULL). The call stack is rather complex, but Eduardo helped tracking it to: select loop -> migrate_fd_put_notify() -> qemu_file_put_notify() -> buffered_put_buffer() -> migrate_fd_put_ready() -> migrate_fd_completed() -> migrate_fd_cleanup(). To be honest, it's not completely clear to me in which cases 's->file' is not closed (on error maybe)? But I doubt this fix will make anything worse. Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'oslib-win32.c')
0 files changed, 0 insertions, 0 deletions