Red Hat Bugzilla – Bug 563141
qemu-img re-base subcommand got Segmentation fault
Last modified: 2013-01-09 17:17:28 EST
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.
There should be a core file from which you can get a backtrace.
(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)
That's with debug symbols installed?
(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 "
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
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