On 07/03/2016 13:49, Dr. David Alan Gilbert wrote: > b) The harder problem is that there's a race where qemu_bh_delete > segs, and I'm not 100% sure why yet - it only does it sometime > (i.e. run virt-test and leave it and it occasionally does it). > From the core it looks like qemu->bh is corrupt (0x10101010...) > so maybe mis has been freed at that point? > I'm suspecting this is the postcopy_ram_listen_thread freeing > mis at the end of it, but I don't know yet.
That should be it. Maybe the patch can simply be reverted, because loadvm_postcopy_handle_run runs from a thread and not a coroutine. Is this correct? However I have a bug or two for you to fix, too: 1) as far as I can see, postcopy_ram_listen_thread is not holding the mutex during the call to qemu_loadvm_state_main. Is that a bug? 2) no one is currently joining mis->listen_thread, I suspect it actually should be QEMU_THREAD_DETACHED. :) Paolo
