Bug 563141 - qemu-img re-base subcommand got Segmentation fault
Summary: qemu-img re-base subcommand got Segmentation fault
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 567602
TreeView+ depends on / blocked
 
Reported: 2010-02-09 11:00 UTC by Keqin Hong
Modified: 2013-01-09 22:17 UTC (History)
8 users (show)

Fixed In Version: kvm-83-161.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 567602 (view as bug list)
Environment:
Last Closed: 2010-03-30 07:56:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0271 0 normal SHIPPED_LIVE Important: kvm security, bug fix and enhancement update 2010-03-29 13:19:48 UTC

Description Keqin Hong 2010-02-09 11:00:40 UTC
Description of problem:
Creating a snapshot chain: baseimg(raw/qcow2/snapshot) <--- sn1 <--- sn2, then running "qemu-img rebase -b base -F $base_fmt sn2" will cause "Segmentation fault".
See steps below for details.

Version-Release number of selected component (if applicable):
kvm-83-157.el5

How reproducible:
100%

CLI:
/usr/libexec/qemu-kvm -m 2G -smp 2 -drive file=sn1,if=virtio,cache=off,boot=on -net nic,model=virtio,vlan=1,macaddr=76:00:40:3F:20:20 -net tap,vlan=1,script=/etc/qemu-ifup -boot c -uuid 17644ecc-d3a1-4d3c-a386-12daf50015f2 -usbdevice tablet -no-hpet -rtc-td-hack -no-kvm-pit-reinjection -monitor stdio -notify all -cpu qemu64,+sse2 -balloon none -startdate now -vnc :1 -name 176-qcow2-test

Steps to Reproduce:
1. install a guest on baseimg (or prepare an existing one as baseimg)
2. create a sn1 based on baseimg
#qemu-img create -b baseimg -f qcow2 sn1
3. boot sn1, write a file inside then shutdown guest
#/usr/liexec/qemu-kvm ...
#dd if=/dev/urandom of=sn1_100M bs=1M count=100
#shutdown -h now
4. create a sn2 based on sn1
#qemu-img create -b sn1 -f qcow2 sn2
5. boot sn2, write a file inside then shutdown guest (this step can also be eliminated)
#/usr/liexec/qemu-kvm ...
#dd if=/dev/urandom of=sn2_50M bs=1M count=50
#shutdown -h now
6. rebase sn2 to baseimg
#qemu-img rebase -b baseimg -F $base_fmt sn2

Actual results:
1. got "Segmentation fault" on step 6
 gdb backtrace couldn't give enough details.
 dmesg: qemu-img[14181]: segfault at 00007fff1d4c11f0 rip 00000000004042c6 rsp 00007fff1d4a03c0 error 4

Expected results:
rebase should succeed, and
1. "qemu-img info sn2" should show the backing file to be baseimg.
2. sn2 can be booted successfully and changes made inside sn1 can be seen, i.e. sn1_100M exists.

Addtional info:
Here is another way to use rebase, though it is not the common case (confirmed with Kevin):
chain: base(raw/qcow2/snapshot) <--- sn1 <--- sn2
using "qemu-img commit sn1", then "qemu-img rebase -b base -F $base_fmt sn2";

However using the commit-then-rebase method did succeed if used for the aforementioned test scenario.

Comment 1 Yaniv Kaul 2010-02-09 11:09:24 UTC
There should be a core file from which you can get a backtrace.

Comment 2 Keqin Hong 2010-02-10 01:23:26 UTC
(In reply to comment #1)
> There should be a core file from which you can get a backtrace.    

Here is the backtrace, but that may not help a lot.

...
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/libselinux.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /lib64/libsepol.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libsepol.so.1

Core was generated by `qemu-img rebase -b win28k-64.raw -F raw sn2'.
Program terminated with signal 11, Segmentation fault.
[New process 19545]
[New process 19547]
[New process 19546]
#0  0x00000000004042c6 in ?? ()
(gdb) bt
#0  0x00000000004042c6 in ?? ()
#1  0x000000342d41d994 in __libc_start_main () from /lib64/libc.so.6
#2  0x0000000000402709 in ?? ()
#3  0x00007fff82fad058 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb)

Comment 3 Yaniv Kaul 2010-02-10 06:19:10 UTC
That's with debug symbols installed?

Comment 4 Keqin Hong 2010-02-10 06:27:49 UTC
(In reply to comment #3)
> That's with debug symbols installed?    

I believe so.
"
[root@localhost ~]# rpm -qa | grep kvm
etherboot-roms-kvm-5.4.4-13.el5
kvm-qemu-img-83-157.el5
kmod-kvm-83-157.el5
kvm-83-157.el5
etherboot-zroms-kvm-5.4.4-13.el5
kvm-tools-83-157.el5
kvm-debuginfo-83-157.el5
"

Comment 15 Keqin Hong 2010-03-03 04:32:31 UTC
Verified by following two scenarios, both succeeded on kvm-83-161.el5.
1. win28k-64.raw <-- sn1 <-- sn2
#qemu-img rebase -b win28k-64.raw -F raw sn2
2. RHEL5.4-64-4k.qcow2 <-- sn1 <-- sn2
#qemu-img rebase -b RHEL5.4-64-4k.qcow2 -F qcow2 sn2

Comment 19 errata-xmlrpc 2010-03-30 07:56:43 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0271.html


Note You need to log in before you can comment on or make changes to this bug.