(gdb) handle SIGUSR1 nostop noprint pass (gdb) b migration/qemu-file.c:295 (gdb) command p f->pos c end
That showed the pos is ever increasing and fails at an offset it never read before. Yet the absolute number was different. $1 = 0 $2 = 8948 $3 = 41423 [...] $11359 = 326387440 $11360 = 326420208 => This was the one failing this time This was a different f->pos than last time, so I wondered if this would change every time. With a less interactive gdb config I got in three tries: 1. 313153311 2. 313313376 3. 313571856 So a different f->pos to fail each time. Different but rather close. I wondered if the reasons I got a higher one when tracing in more detail printing all offsets could be that there still is something copied/synced and only slowly gets available. I stepped through rather slowly and got to 322429260 this time. So slower continuing on the iteration over qemu_fill_buffer makes it fail "later"? Finally it is surely interesting which channel that actually is- likely the migration socket? And yes, ioc->name in qio_channel_read is: $8 = 0x56ab78e5c0 "migration-socket-incoming -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1711602 Title: --copy-storage-all failing with qemu 2.10 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1711602/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
