Bug 879159

Summary: core dump when migration with usb-storage using remote-viewer connection
Product: Red Hat Enterprise Linux 6 Reporter: Sibiao Luo <sluo>
Component: spice-serverAssignee: Uri Lublin <uril>
Status: CLOSED DUPLICATE QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 6.4CC: acathrow, cfergeau, chayang, dblechte, dyasny, juzhang, mazhang, michen, mkenneth, mkrcmari, qzhang, qzhou, sluo
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-22 09:46:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
both the source and destination of qemu logs output. none

Description Sibiao Luo 2012-11-22 08:52:13 UTC
Description of problem:
migration with usb-storage using remote-viewer to connect, then it can migration successfully, but after a while the destination qemu core dump.

Version-Release number of selected component (if applicable):
host info:
kernel-2.6.32-342.el6.x86_64
qemu-kvm-0.12.1.2-2.334.el6.x86_64
spice-server-0.12.0-2.el6.x86_64
spice-gtk-0.14-5.el6.x86_64
virt-viewer-0.5.2-16.el6.x86_64
guest info:
RHEL6.4-20121106.0-6.4-x86_64
kernel-2.6.32-342.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1.boot a guest with usb-storage using remote-viewer to connect.
eg:...-device usb-ehci,id=ehci -drive file=/dev/vg-90.100-sluo/lv-90-100-usb-storage1,if=none,format=qcow2,cache=none,werror=stop,rerror=stop,aio=native,id=usb-stick -device usb-storage,bus=ehci.0,drive=usb-stick,id=usb-disk,bootindex=3
2.do live migration.
(qemu) __com.redhat_spice_migrate_info 10.66.11.229 5931
(qemu) migrate -d tcp:10.66.11.229:5888

Actual results:
after step 2, the destination qemu core dump after migration complete successfully. i will attach all the qemu output logs later.
- destination qemu
(qemu) info status 
VM status: running
(qemu) [New Thread 0x7fffe59fb700 (LWP 24007)]
(/usr/bin/gdb:23971): SpiceWorker-CRITICAL **: red_worker.c:5467:lz_usr_error: stride != width*bytes_per_pixel (rgb) 448 != 445 * 1 (11)

Detaching after fork from child process 24008.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe75fe700 (LWP 23986)]
0x00007ffff57468a5 in raise () from /lib64/libc.so.6

(gdb) bt
#0  0x00007ffff57468a5 in raise () from /lib64/libc.so.6
#1  0x00007ffff5748085 in abort () from /lib64/libc.so.6
#2  0x00007ffff5fa0c15 in spice_logv (log_domain=0x7ffff601cd7c "SpiceWorker", log_level=SPICE_LOG_LEVEL_CRITICAL, strloc=0x7ffff601d139 "red_worker.c:5467", 
    function=0x7ffff601ee8e "lz_usr_error", format=0x7ffff602916a "%s", args=0x7fffe75fd370) at log.c:109
#3  0x00007ffff5fa0d4a in spice_log (log_domain=<value optimized out>, log_level=<value optimized out>, strloc=<value optimized out>, function=<value optimized out>, 
    format=<value optimized out>) at log.c:123
#4  0x00007ffff5f656b4 in lz_usr_error (usr=0x7fff4c1d7720, fmt=<value optimized out>) at red_worker.c:5467
#5  0x00007ffff5fa5a8e in lz_encode (lz=0x7ffff7c2e010, type=LZ_IMAGE_TYPE_A8, width=445, height=184, top_down=1, lines=0x0, num_lines=0, stride=448, 
    io_ptr=0x7fff4c260ac0 "  ZL", num_io_bytes=65536) at lz.c:524
#6  0x00007ffff5f6cda0 in red_lz_compress_image (dcc=0x7fff4c270ce0, dest=0x7fffe75fd780, src=0x7fffe75fd7c0, o_comp_data=0x7fffe75fd7f0, group_id=<value optimized out>)
    at red_worker.c:6038
#7  0x00007ffff5f7a716 in red_marshall_image (rcc=0x7fff4c270ce0, pipe_item=0x7fff4e493af0) at red_worker.c:8600
#8  display_channel_send_item (rcc=0x7fff4c270ce0, pipe_item=0x7fff4e493af0) at red_worker.c:8911
#9  0x00007ffff5f5a563 in red_channel_client_send_item (rcc=0x7fff4c270ce0) at red_channel.c:507
#10 red_channel_client_push (rcc=0x7fff4c270ce0) at red_channel.c:1088
#11 0x00007ffff5f65a59 in red_push_surface_image (dcc=0x7fff4c270ce0, surface_id=<value optimized out>) at red_worker.c:5095
#12 0x00007ffff5f7cc1b in red_handle_drawable_surfaces_client_synced (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:1388
#13 red_pipe_add_drawable (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:1444
#14 red_pipes_add_drawable (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:1456
#15 red_process_drawable (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:3958
#16 red_process_commands (worker=0x7fff4c0008c0, ring_is_empty=0x7fffe75fdbdc, max_pipe_size=50) at red_worker.c:4902
#17 0x00007ffff5f7fcca in red_worker_main (arg=<value optimized out>) at red_worker.c:11798
#18 0x00007ffff773c851 in start_thread () from /lib64/libpthread.so.0
#19 0x00007ffff57fc90d in clone () from /lib64/libc.so.6
(gdb) 

Expected results:
the guest should work well after migration complete, the qemu should no any core dump.

Additional info:

Comment 1 Sibiao Luo 2012-11-22 08:56:54 UTC
Created attachment 649583 [details]
both the source and destination of qemu logs output.

Comment 2 Sibiao Luo 2012-11-22 08:57:59 UTC
my host cpuinfo:
processor	: 7
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
stepping	: 7
cpu MHz		: 1600.000
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 3
cpu cores	: 4
apicid		: 7
initial apicid	: 7
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 6784.60
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Comment 3 Sibiao Luo 2012-11-22 08:58:49 UTC
qemu-kvm command line:

/usr/libexec/qemu-kvm -M rhel6.4.0 -cpu SandyBridge -enable-kvm -m 2048 -smp 2,sockets=1,cores=2,threads=1 -name use_device -uuid 990ea161-6b67-47b2-b803-19fb01d30d30 -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x3 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port2 -drive file=/home/RHEL6.4-20121106.0-6.4-x86_64.qcow2,if=none,id=drive-scsi-disk,format=qcow2,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi0,addr=0x4 -device scsi-disk,drive=drive-scsi-disk,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=08:2E:5F:0A:0D:B1,bus=pci.0,addr=0x5,bootindex=2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -spice port=5931,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.vram_size=67108864 -nodefaults -boot menu=on -monitor stdio -device usb-ehci,id=ehci -drive file=/dev/vg-90.100-sluo/lv-90-100-usb-storage1,if=none,format=qcow2,cache=none,werror=stop,rerror=stop,aio=native,id=usb-stick -device usb-storage,bus=ehci.0,drive=usb-stick,id=usb-disk,bootindex=3

Comment 5 Marian Krcmarik 2012-11-22 09:46:25 UTC

*** This bug has been marked as a duplicate of bug 876685 ***