Re: [Qemu-devel] [PULL 10/40] migration: Delay start of migration main routines

[Kevin Wolf <kwolf@redhat.com>]

Am 18.05.2018 um 12:34 hat Dr. David Alan Gilbert geschrieben:
> * Kevin Wolf (kwolf@redhat.com) wrote:
> > Am 16.05.2018 um 01:39 hat Juan Quintela geschrieben:
> > > We need to make sure that we have started all the multifd threads.
> > > 
> > > Signed-off-by: Juan Quintela <quintela@redhat.com>
> > > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> > 
> > This commit makes qemu-iotests 091 hang for me. Either it breaks
> > backward compatibility intentionally and we need to update the test
> > case, or there is a bug somewhere.
> 
> It's not an intentional break.
> And the avocado tcp and exec migrations pass OK, so hmm.

In case it helps, 169 fails as well and I got a core dump of an aborting
QEMU process:

(gdb) bt
#0  0x00007ff079f779fb in raise () at /lib64/libc.so.6
#1  0x00007ff079f79800 in abort () at /lib64/libc.so.6
#2  0x00007ff079f700da in __assert_fail_base () at /lib64/libc.so.6
#3  0x00007ff079f70152 in  () at /lib64/libc.so.6
#4  0x000055c2126f067b in bdrv_close_all () at block.c:3375
#5  0x000055c2123c54a6 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4682

If I understand correctly, that assertion failure means that someone is
still holding a reference to a block device after all user-owned
references have been closed. I suppose this was the source qemu and
the migration hasn't been completed properly, though I haven't looked at
the code yet and this idea might be completely wrong.

Anyway, 091 is certainly the simpler test case to play with, but maybe
this gives you another hint.

Kevin