From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ubg2J-0007MN-Nk for qemu-devel@nongnu.org; Sun, 12 May 2013 19:50:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ubg2I-0005Xm-6O for qemu-devel@nongnu.org; Sun, 12 May 2013 19:50:39 -0400 Received: from indium.canonical.com ([91.189.90.7]:39715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ubg2H-0005Xh-UB for qemu-devel@nongnu.org; Sun, 12 May 2013 19:50:38 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.71 #1 (Debian)) id 1Ubg2H-0005qC-2Y for ; Sun, 12 May 2013 23:50:37 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id EB1D62E8085 for ; Sun, 12 May 2013 23:50:36 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 May 2013 23:43:31 -0000 From: "Brian J. Murrell" Sender: bounces@canonical.com References: <20130512135934.14853.36568.malonedeb@soybean.canonical.com> <20130512211424.14822.35652.malone@gac.canonical.com> Message-Id: <51902923.9030305@interlinx.bc.ca> Errors-To: bounces@canonical.com Subject: Re: [Qemu-devel] [Bug 1179219] Re: segfault in alloc_refcount_block Reply-To: Bug 1179219 <1179219@bugs.launchpad.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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=3D6441 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=3D1486&type=3Dbug For convenience I will paste the segfaulting thread's stack trace here: :#0 0x00007f0d4d9fadd5 in alloc_refcount_block (bs=3D0x7f0d4fc38010, off= set=3D864752701576067072, length=3D, addend=3D-1) at /= usr/src/debug/qemu-kvm-0.12.1.2/block/qcow2-refcount.c:335 : refcount_table_index =3D 402681856 : new_block =3D 131072 : table_size =3D : new_table =3D : old_table_offset =3D : old_free_cluster_index =3D : last_table_size =3D : refcount_block_clusters =3D : meta_offset =3D 2147483648 : table_offset =3D 2147614720 : s =3D 0x10000 : blocks_used =3D 1 : old_table_size =3D : ret =3D : new_blocks =3D 0x7f0d504babd0 : i =3D : table_clusters =3D : data =3D "\000\000\000\000\000\000\000\000e\240Y\003" : blocks_clusters =3D : block =3D :#1 update_refcount (bs=3D0x7f0d4fc38010, offset=3D864752701576067072, l= ength=3D, addend=3D-1) at /usr/src/debug/qemu-kvm-0.12= .1.2/block/qcow2-refcount.c:460 : block_index =3D : refcount =3D : cluster_index =3D 13195079064576 : table_index =3D 402681856 : s =3D 0x7f0d4fc35770 : start =3D 864752701576052736 : last =3D 864752701576118272 : cluster_offset =3D 864752701576052736 : refcount_block =3D 0x0 : old_table_index =3D : ret =3D :#2 0x00007f0d4d9fb710 in qcow2_free_clusters (bs=3D0x7f0d4fc38010, offs= et=3D864752701576067072, size=3D65536) at /usr/src/debug/qemu-kvm-0.12.1.2/= block/qcow2-refcount.c:640 : ret =3D :#3 0x00007f0d4d9fd03e in qcow2_alloc_cluster_link_l2 (bs=3D0x7f0d4fc380= 10, m=3D) at /usr/src/debug/qemu-kvm-0.12.1.2/block/qc= ow2-cluster.c:674 : s =3D : i =3D : j =3D : l2_index =3D 2032 : ret =3D : old_cluster =3D 0x7f0d4fd2b5e0 : start_sect =3D : l2_offset =3D 145358848 : l2_table =3D 0x0 : cluster_offset =3D : cow =3D :#4 0x00007f0d4d9f7d39 in qcow2_co_writev (bs=3D0x7f0d4fc38010, sector_n= um=3D, remaining_sectors=3D216, qiov=3D0x7f0d40051b40)= at /usr/src/debug/qemu-kvm-0.12.1.2/block/qcow2.c:632 : s =3D 0x7f0d4fc35770 : index_in_cluster =3D 120 : n_end =3D : ret =3D : cur_nr_sectors =3D 8 : cluster_offset =3D 274333696 : hd_qiov =3D {iov =3D 0x7f0d4001bcb0, niov =3D 1, nalloc =3D 26, = size =3D 4096} : bytes_done =3D : cluster_data =3D 0x0 : l2meta =3D {offset =3D 2817585152, cluster_offset =3D 274333696,= n_start =3D 120, nb_available =3D 128, nb_clusters =3D 1, depends_on =3D 0= x0, dependent_requests =3D {entries =3D {tqh_first =3D 0x0, tqh_last =3D 0x= 7f0cf43dde78}}, next_in_flight =3D {le_next =3D 0x0, le_prev =3D 0x7f0cefff= ee88}} : __PRETTY_FUNCTION__ =3D "qcow2_co_writev" :#5 0x00007f0d4d9e20b9 in bdrv_co_do_writev (bs=3D0x7f0d4fc38010, sector= _num=3D5503096, nb_sectors=3D216, qiov=3D0x7f0d40051b40, flags=3D) at /usr/src/debug/qemu-kvm-0.12.1.2/block.c:2081 : drv =3D 0x7f0d4de96f80 : req =3D {bs =3D 0x7f0d4fc38010, sector_num =3D 5503096, nb_secto= rs =3D 216, is_write =3D true, list =3D {le_next =3D 0x0, le_prev =3D 0x7f0= cefffef28}, co =3D 0x7f0d40002af0, wait_queue =3D {entries =3D {tqh_first = =3D 0x0, tqh_last =3D 0x7f0cf43ddf40}}} : ret =3D :#6 0x00007f0d4d9e2161 in bdrv_co_do_rw (opaque=3D0x7f0d4003ced0) at /us= r/src/debug/qemu-kvm-0.12.1.2/block.c:3497 : acb =3D 0x7f0d4003ced0 : bs =3D :#7 0x00007f0d4d9e7eeb in coroutine_trampoline (i0=3D, i1=3D) at /usr/src/debug/qemu-kvm-0.12.1.2/corouti= ne-ucontext.c:129 : self =3D 0x7f0d40002af0 : co =3D 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