From: "Brian J. Murrell" <brian@interlinx.bc.ca>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1179219] Re: segfault in alloc_refcount_block
Date: Sun, 12 May 2013 23:43:31 -0000 [thread overview]
Message-ID: <51902923.9030305@interlinx.bc.ca> (raw)
In-Reply-To: 20130512211424.14822.35652.malone@gac.canonical.com
On 13-05-12 05:14 PM, Michael Tokarev wrote:
> First, having a single qcow2 file open for read-write access by more
> than one process in unsupported.
But I don't, if I understand how qcow2 snapshots work. Let me apologize
if I was not clear. Each of the VMs have their own snapshot of the
common "origin" qcow2 disk. If I understand correctly in such a
configuration, only one VM has each snapshot qcow2 open for read-write
access and they all have the "origin" open read-only, is that correct?
Surely that must be supported, yes?
> Second, this version of qemu/kvm is too old to be supported upstream,
> it's a few years old already and there has been *lots* of changes since
> that version.
That's fair enough. It's unfortunate that this is the version that
Redhat supply with current EL6. I am working on standing up an FC18
host instead.
Cheers.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1179219
Title:
segfault in alloc_refcount_block
Status in QEMU:
Invalid
Bug description:
On CentOS-6.4.latest, I am trying to run several KVM VMs with
snapshots of a single qcow2 image. Randomly some VMs will crash
though. There's a downstream bug report at
http://bugs.centos.org/view.php?id=6441 and included in that is an
"abrt" crash report that contains the full stack trace as well as
disassembly etc. That report is at
http://bugs.centos.org/file_download.php?file_id=1486&type=bug
For convenience I will paste the segfaulting thread's stack trace
here:
:#0 0x00007f0d4d9fadd5 in alloc_refcount_block (bs=0x7f0d4fc38010, offset=864752701576067072, length=<value optimized out>, addend=-1) at /usr/src/debug/qemu-kvm-0.12.1.2/block/qcow2-refcount.c:335
: refcount_table_index = 402681856
: new_block = 131072
: table_size = <value optimized out>
: new_table = <value optimized out>
: old_table_offset = <value optimized out>
: old_free_cluster_index = <value optimized out>
: last_table_size = <value optimized out>
: refcount_block_clusters = <value optimized out>
: meta_offset = 2147483648
: table_offset = 2147614720
: s = 0x10000
: blocks_used = 1
: old_table_size = <value optimized out>
: ret = <value optimized out>
: new_blocks = 0x7f0d504babd0
: i = <value optimized out>
: table_clusters = <value optimized out>
: data = "\000\000\000\000\000\000\000\000e\240Y\003"
: blocks_clusters = <value optimized out>
: block = <value optimized out>
:#1 update_refcount (bs=0x7f0d4fc38010, offset=864752701576067072, length=<value optimized out>, addend=-1) at /usr/src/debug/qemu-kvm-0.12.1.2/block/qcow2-refcount.c:460
: block_index = <value optimized out>
: refcount = <value optimized out>
: cluster_index = 13195079064576
: table_index = 402681856
: s = 0x7f0d4fc35770
: start = 864752701576052736
: last = 864752701576118272
: cluster_offset = 864752701576052736
: refcount_block = 0x0
: old_table_index = <value optimized out>
: ret = <value optimized out>
:#2 0x00007f0d4d9fb710 in qcow2_free_clusters (bs=0x7f0d4fc38010, offset=864752701576067072, size=65536) at /usr/src/debug/qemu-kvm-0.12.1.2/block/qcow2-refcount.c:640
: ret = <value optimized out>
:#3 0x00007f0d4d9fd03e in qcow2_alloc_cluster_link_l2 (bs=0x7f0d4fc38010, m=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/block/qcow2-cluster.c:674
: s = <value optimized out>
: i = <value optimized out>
: j = <value optimized out>
: l2_index = 2032
: ret = <value optimized out>
: old_cluster = 0x7f0d4fd2b5e0
: start_sect = <value optimized out>
: l2_offset = 145358848
: l2_table = 0x0
: cluster_offset = <value optimized out>
: cow = <value optimized out>
:#4 0x00007f0d4d9f7d39 in qcow2_co_writev (bs=0x7f0d4fc38010, sector_num=<value optimized out>, remaining_sectors=216, qiov=0x7f0d40051b40) at /usr/src/debug/qemu-kvm-0.12.1.2/block/qcow2.c:632
: s = 0x7f0d4fc35770
: index_in_cluster = 120
: n_end = <value optimized out>
: ret = <value optimized out>
: cur_nr_sectors = 8
: cluster_offset = 274333696
: hd_qiov = {iov = 0x7f0d4001bcb0, niov = 1, nalloc = 26, size = 4096}
: bytes_done = <value optimized out>
: cluster_data = 0x0
: l2meta = {offset = 2817585152, cluster_offset = 274333696, n_start = 120, nb_available = 128, nb_clusters = 1, depends_on = 0x0, dependent_requests = {entries = {tqh_first = 0x0, tqh_last = 0x7f0cf43dde78}}, next_in_flight = {le_next = 0x0, le_prev = 0x7f0cefffee88}}
: __PRETTY_FUNCTION__ = "qcow2_co_writev"
:#5 0x00007f0d4d9e20b9 in bdrv_co_do_writev (bs=0x7f0d4fc38010, sector_num=5503096, nb_sectors=216, qiov=0x7f0d40051b40, flags=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/block.c:2081
: drv = 0x7f0d4de96f80
: req = {bs = 0x7f0d4fc38010, sector_num = 5503096, nb_sectors = 216, is_write = true, list = {le_next = 0x0, le_prev = 0x7f0cefffef28}, co = 0x7f0d40002af0, wait_queue = {entries = {tqh_first = 0x0, tqh_last = 0x7f0cf43ddf40}}}
: ret = <value optimized out>
:#6 0x00007f0d4d9e2161 in bdrv_co_do_rw (opaque=0x7f0d4003ced0) at /usr/src/debug/qemu-kvm-0.12.1.2/block.c:3497
: acb = 0x7f0d4003ced0
: bs = <value optimized out>
:#7 0x00007f0d4d9e7eeb in coroutine_trampoline (i0=<value optimized out>, i1=<value optimized out>) at /usr/src/debug/qemu-kvm-0.12.1.2/coroutine-ucontext.c:129
: self = 0x7f0d40002af0
: co = 0x7f0d40002af0
:#8 0x00007f0d4b31bb70 in ?? () from /lib64/libc-2.12.so
:No symbol table info available.
:#9 0x00007f0d44c0eed0 in ?? ()
:No symbol table info available.
:#10 0x0000000000000000 in ?? ()
It would appear, according to RPM at least that I am using 0.12.1.2 of
qemu/kvm on this machine.
I'm happy to provide any additional information test patches, etc.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1179219/+subscriptions
next prev parent reply other threads:[~2013-05-12 23:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-12 13:59 [Qemu-devel] [Bug 1179219] [NEW] segfault in alloc_refcount_block Brian J. Murrell
2013-05-12 21:14 ` [Qemu-devel] [Bug 1179219] " Michael Tokarev
2013-05-12 23:43 ` Brian J. Murrell [this message]
2013-05-15 8:45 ` Stefan Hajnoczi
2013-05-15 11:07 ` Brian J. Murrell
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=51902923.9030305@interlinx.bc.ca \
--to=brian@interlinx.bc.ca \
--cc=1179219@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.