RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1254541 - qemu core dump when do system reset
Summary: qemu core dump when do system reset
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.2
Hardware: x86_64
OS: Unspecified
medium
high
Target Milestone: rc
: ---
Assignee: Ademar Reis
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-18 11:10 UTC by Xueqiang Wei
Modified: 2016-01-13 14:11 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-13 14:11:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Xueqiang Wei 2015-08-18 11:10:22 UTC 
Description of problem:

boot a guest rhel6.6-64, and then repeat execute the command {"execute": "system_reset"} 20 times.

qemu will core dump. Hit this issue by autotest script.
(virt.qemu.smp_16.32768m.repeat1.Host_RHEL.7.2.spice.qcow2.virtio_blk.up.virtio_net.RHEL.6.6.x86_64.io-github-autotest-qemu.system_reset_bootable).

I tried 20 times manually, not hit this issue.


Version-Release number of selected component (if applicable):

kernel-3.10.0-304.el7.x86_64
qemu-kvm-1.5.3-101.el7



How reproducible:
1/20


Steps to Reproduce:
1.boot a guest:
/usr/libexec/qemu-kvm \
    -name 'virt-tests-vm1'  \
    -sandbox off  \
    -machine pc  \
    -nodefaults  \
    -vga qxl \
    -device intel-hda,bus=pci.0,addr=03 \
    -device hda-duplex  \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20150818-114906-NqNVoKkf,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=qmp_id_catch_monitor,path=/tmp/monitor-catch_monitor-20150818-114906-NqNVoKkf,server,nowait \
    -mon chardev=qmp_id_catch_monitor,mode=control  \
    -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150818-114906-NqNVoKkf,server,nowait \
    -device isa-serial,chardev=serial_id_serial0 \
    -device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=04  \
    -chardev socket,id=devvs,path=/tmp/virtio_port-vs-20150818-114906-NqNVoKkf,server,nowait \
    -device virtserialport,chardev=devvs,name=vs,id=vs,bus=virtio_serial_pci0.0  \
    -chardev socket,id=seabioslog_id_20150818-114906-NqNVoKkf,path=/tmp/seabios-20150818-114906-NqNVoKkf,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20150818-114906-NqNVoKkf,iobase=0x402 \
    -device nec-usb-xhci,id=usb1,bus=pci.0,addr=05 \
    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,file=/home/autotest-devel/client/tests/virt/shared/data/images/rhel66-64-virtio.qcow2 \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=06 \
    -device virtio-net-pci,mac=9a:49:4a:4b:4c:4d,id=idDCKv9p,vectors=4,netdev=idV0i8nF,bus=pci.0,addr=07  \
    -netdev tap,id=idV0i8nF,vhost=on  \
    -m 32768  \
    -smp 16,maxcpus=16,cores=8,threads=1,sockets=2  \
    -cpu 'Opteron_G4',+kvm_pv_unhalt \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -spice port=8001,disable-ticketing \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm \
    -monitor stdio \
    -qmp tcp:0:4444,server,nowait \

2. run the below commands:
{"execute":"qmp_capabilities"}

3. repeat system reset 20 times
{"execute": "system_reset"}


Actual results:
qemu core dump after system reset 16 times.

the qemu output: [qemu output] /tmp/aexpect/wxmTFAnD/aexpect-8KnTSL.sh: line 1: 20315 Aborted                 (core dumped) /usr/libexec/qemu-kvm -S -name 'virt-tests-vm1' -sandbox off -machine pc -nodefaults -vga qxl -device intel-hda,bus=pci.0,addr=03 -device hda-duplex -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20150818-114906-NqNVoKkf,server,nowait -mon chardev=qmp_id_qmpmonitor1,mode=control -chardev socket,id=qmp_id_catch_monitor,path=/tmp/monitor-catch_monitor-20150818-114906-NqNVoKkf,server,nowait -mon chardev=qmp_id_catch_monitor,mode=control -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20150818-114906-NqNVoKkf,server,nowait -device isa-serial,chardev=serial_id_serial0 -device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=04 -chardev socket,id=devvs,path=/tmp/virtio_port-vs-20150818-114906-NqNVoKkf,server,nowait -device virtserialport,chardev=devvs,name=vs,id=vs,bus=virtio_serial_pci0.0 -chardev socket,id=seabioslog_id_20150818-114906-NqNVoKkf,path=/tmp/seabios-20150818-114906-NqNVoKkf,server,nowait -device isa-debugcon,chardev=seabioslog_id_20150818-114906-NqNVoKkf,iobase=0x402 -device nec-usb-xhci,id=usb1,bus=pci.0,addr=05 -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,file=/home/autotest-devel/client/tests/virt/shared/data/images/rhel66-64-virtio.qcow2 -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=06 -device virtio-net-pci,mac=9a:49:4a:4b:4c:4d,id=idDCKv9p,vectors=4,netdev=idV0i8nF,bus=pci.0,addr=07 -netdev tap,id=idV0i8nF,vhost=on,vhostfd=24,fd=23 -m 32768 -smp 16,maxcpus=16,cores=8,threads=1,sockets=2 -cpu 'Opteron_G4',+kvm_pv_unhalt -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 -spice port=3000,password=123456,addr=0,tls-port=3200,x509-dir=/tmp/spice_x509d,tls-channel=main,tls-channel=inputs,image-compression=auto_glz,zlib-glz-wan-compression=auto,streaming-video=all,agent-mouse=on,playback-compression=on,ipv4 -rtc base=utc,clock=host,driftfix=slew -boot order=cdn,once=c,menu=off,strict=off -enable-kvm
08/18 11:54:10 INFO |   aexpect:0965| [qemu output] (Process terminated with status 134)

qemu core dump:
# gdb core 
(gdb) bt full
#0  0x00007f0b3a9775d7 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007f0b3a978cc8 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007f0b41b3a8bc in kvm_cpu_exec (env=env@entry=0x7f0b44850110) at /usr/src/debug/qemu-1.5.3/kvm-all.c:1667
        cpu = 0x7f0b44850000
        __func__ = "kvm_cpu_exec"
        run = 0x7f0b418aa000
        ret = <optimized out>
        run_ret = -1
#3  0x00007f0b41aed265 in qemu_kvm_cpu_thread_fn (arg=0x7f0b44850110) at /usr/src/debug/qemu-1.5.3/cpus.c:802
        env = 0x7f0b44850110
        cpu = 0x7f0b44850000
        __func__ = "qemu_kvm_cpu_thread_fn"
        r = <optimized out>
#4  0x00007f0b3e9e1dc5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5  0x00007f0b3aa381bd in clone () from /lib64/libc.so.6
No symbol table info available.


Expected results:
qemu works well.


Additional info:
Comment 2 Ademar Reis 2015-08-19 23:32:20 UTC 
Can you please upload/attach the core file from QEMU?
Comment 4 Xueqiang Wei 2015-08-21 03:08:09 UTC 
Additional info:

Host cpu:

processor	: 31
vendor_id	: AuthenticAMD
cpu family	: 21
model		: 1
model name	: AMD Opteron(TM) Processor 6272                 
stepping	: 2
microcode	: 0x600063d
cpu MHz		: 2100.091
cache size	: 2048 KB
physical id	: 1
siblings	: 16
core id		: 7
cpu cores	: 8
apicid		: 79
initial apicid	: 47
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 mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips	: 4199.77
TLB size	: 1536 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb


Guest info:

RHEL.6.6.x86_64
kernel-2.6.32-504.33.1.el6.x86_64
Comment 6 Xueqiang Wei 2016-01-13 02:19:19 UTC 
repeat 300 times on new version build as below, and not hit this issue.
host:
kernel-3.10.0-327.2.1.el7.x86_64
qemu-kvm-1.5.3-105.el7
Comment 7 Ademar Reis 2016-01-13 14:11:23 UTC 
(In reply to Xueqiang Wei from comment #6)
> repeat 300 times on new version build as below, and not hit this issue.
> host:
> kernel-3.10.0-327.2.1.el7.x86_64
> qemu-kvm-1.5.3-105.el7

OK, closing it for now. Please reopen if it ever happens again (and attach the coredump if possible).
Note You need to log in before you can comment on or make changes to this bug.