From: Avi Kivity <avi@redhat.com>
To: qemu-devel <qemu-devel@nongnu.org>,
KVM list <kvm@vger.kernel.org>,
Juan Quintela <quintela@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>
Subject: Re: Migration issues in qemu.git
Date: Mon, 02 Aug 2010 12:42:21 +0300 [thread overview]
Message-ID: <4C5692FD.80808@redhat.com> (raw)
In-Reply-To: <4C568A85.9040500@redhat.com>
On 08/02/2010 12:06 PM, Avi Kivity wrote:
> I'm hitting some migration issues merging qemu.git into qemu-kvm.git:
>
> 1. Crash in mig_cancel test:
>
> (gdb) bt
> #0 0x0000003a91c83dbb in memcpy () from /lib64/libc.so.6
> #1 0x000000000049c2ff in qemu_get_buffer (f=0x302d870, buf=<value
> optimized out>, size1=4096) at /usr/include/bits/string3.h:52
> #2 0x0000000000409464 in ram_load (f=0x302d870, opaque=<value
> optimized out>, version_id=4) at
> /build/home/tlv/akivity/qemu-kvm/arch_init.c:407
> #3 0x000000000049cb4c in qemu_loadvm_state (f=0x302d870) at
> savevm.c:1708
> #4 0x0000000000494169 in process_incoming_migration (f=<value
> optimized out>) at migration.c:63
> #5 0x0000000000494517 in tcp_accept_incoming_migration (opaque=<value
> optimized out>) at migration-tcp.c:163
> #6 0x000000000041b67e in main_loop_wait (nonblocking=<value optimized
> out>) at /build/home/tlv/akivity/qemu-kvm/vl.c:1300
> #7 0x00000000004314e7 in kvm_main_loop () at
> /build/home/tlv/akivity/qemu-kvm/qemu-kvm.c:1710
> #8 0x000000000041c67f in main_loop (argc=<value optimized out>,
> argv=<value optimized out>, envp=<value optimized out>)
> at /build/home/tlv/akivity/qemu-kvm/vl.c:1340
> #9 main (argc=<value optimized out>, argv=<value optimized out>,
> envp=<value optimized out>) at /build/home/tlv/akivity/qemu-kvm/vl.c:3069
>
> This is on the incoming side so the test completes successfully, only
> leaving a core dump to fill my disks.
This appears to be
> static inline void *host_from_stream_offset(QEMUFile *f,
> ram_addr_t offset,
> int flags)
> {
> static RAMBlock *block = NULL;
> char id[256];
> uint8_t len;
>
> if (flags & RAM_SAVE_FLAG_CONTINUE) {
> if (!block) {
> fprintf(stderr, "Ack, bad migration stream!\n");
> return NULL;
> }
>
> return block->host + offset;
> }
with block == NULL, if my gdb-fu got a static variable in an inlined
function examined correctly.
I don't see any special reason for block to be NULL on a cancelled
migration. Though perhaps the incoming stream was terminated without us
noticing, and we're migrating from some random buffer and confusing the
code?
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-08-02 9:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-02 9:06 Migration issues in qemu.git Avi Kivity
2010-08-02 9:42 ` Avi Kivity [this message]
2010-08-02 13:12 ` Alex Williamson
2010-08-02 13:15 ` Avi Kivity
2010-08-02 13:15 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C5692FD.80808@redhat.com \
--to=avi@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox