On Thu, 04/30 17:50, Paolo Bonzini wrote:
> John, Fam,
>
> I got this report offlist. This happens if a bit in the hbitmap is
> cleared and the HBitmap has _not_ yet reached the bit. See this comment
> in include/qemu/hbitmap.h:
>
> * Resetting bits before the current
> * position of the iterator is also okay. However, concurrent
> * resetting of bits can lead to unexpected behavior if the iterator
> * has not yet reached those bits.
>
> Can you please take a look?
Since the gdb output is suggesting 1.5.3, it's worth to trying 2.3 which has
this:
commit c4237dfa635900e4d1cdc6038d5efe3507f45f0c
Author: Vladimir Sementsov-Ogievskiy <vsement...@parallels.com>
Date: Thu Nov 27 12:40:46 2014 +0300
block: fix spoiling all dirty bitmaps by mirror and migration
Mirror and migration use dirty bitmaps for their purposes, and since
commit [block: per caller dirty bitmap] they use their own bitmaps, not
the global one. But they use old functions bdrv_set_dirty and
bdrv_reset_dirty, which change all dirty bitmaps.
Named dirty bitmaps series by Fam and Snow are affected: mirroring and
migration will spoil all (not related to this mirroring or migration)
named dirty bitmaps.
This patch fixes this by adding bdrv_set_dirty_bitmap and
bdrv_reset_dirty_bitmap, which change concrete bitmap. Also, to prevent
such mistakes in future, old functions bdrv_(set,reset)_dirty are made
static, for internal block usage.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@parallels.com>
CC: John Snow <js...@redhat.com>
CC: Fam Zheng <f...@redhat.com>
CC: Denis V. Lunev <d...@openvz.org>
CC: Stefan Hajnoczi <stefa...@redhat.com>
CC: Kevin Wolf <kw...@redhat.com>
Reviewed-by: John Snow <js...@redhat.com>
Reviewed-by: Fam Zheng <f...@redhat.com>
Message-id: 1417081246-3593-1-git-send-email-vsement...@parallels.com
Signed-off-by: Max Reitz <mre...@redhat.com>
Fam
>
> Thanks,
>
> Paolo
>
> -------- Forwarded Message --------
> Subject: qemu drive mirror assert fault
> Date: Wed, 29 Apr 2015 10:50:28 +0800
> From: wangxiaolong <wangxiaol...@ucloud.cn>
> To: pbonzini <pbonz...@redhat.com>
>
> hello,
>
> I used drive mirror to do live migration, and I run into such an assert
> fault:
>
> (gdb) bt
>
> #0 0x00007fd2c6e678a5 in raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>
> #1 0x00007fd2c6e69085 in abort () at abort.c:92
>
> #2 0x00007fd2c6e60a1e in __assert_fail_base (fmt=<value optimized out>,
> assertion=0x7fd2ca215aa0 "cur", file=0x7fd2ca215a78 "util/hbitmap.c",
> line=<value optimized out>,
>
> function=<value optimized out>) at assert.c:96
>
> #3 0x00007fd2c6e60ae0 in __assert_fail (assertion=0x7fd2ca215aa0 "cur",
> file=0x7fd2ca215a78 "util/hbitmap.c", line=129, function=0x7fd2ca215bf0
> "hbitmap_iter_skip_words")
>
> at assert.c:105
>
> #4 0x00007fd2ca1b3bb8 in hbitmap_iter_skip_words (hbi=<value optimized
> out>) at util/hbitmap.c:129
>
> #5 0x00007fd2c9f8f8e0 in hbitmap_iter_next (opaque=0x7fd2cc59c730) at
> /usr/src/debug/qemu-kvm-1.5.3/include/qemu/hbitmap.h:166
>
> #6 mirror_iteration (opaque=0x7fd2cc59c730) at block/mirror.c:163
>
> #7 mirror_run (opaque=0x7fd2cc59c730) at block/mirror.c:407
>
> #8 0x00007fd2c9fc45bb in coroutine_trampoline (i0=<value optimized
> out>, i1=<value optimized out>) at coroutine-ucontext.c:118
>
> #9 0x00007fd2c6e78b70 in ?? () from /lib64/libc-2.12.so
>
> #10 0x00007fff53eede80 in ?? ()
>
> #11 0x0000000000000000 in ?? ()
>
>
> and I just can’t figure out what is the cause of this situation,
> could you help me figure it out, thanks!
>
>
>
>
