Bug 994414

Might be needed in 6.5 too.

Hmm.  Stacktrace looks like a timer being called after chardev removal.  Can't see a bug in the code closing the pty, the timer is cleaned up properly.  Also can't reproduce the bug.

Does it happen on every attempt or only now and then?
Can you still reproduce it with the latest rhel7 builds?

Pinned it: http://patchwork.ozlabs.org/patch/269003/

Fix included in qemu-kvm-1.5.3-11.el7

Tried to reproduce this issue with same CLI as well as same version of qemu-kvm mentioned in Comment #0. 
After hot removing chardev, I got bt as follows, but I am not very sure if they are the same issue.


Program terminated with signal 11, Segmentation fault.
#0  0x00007f4fe8691e40 in ?? ()
Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-12.1.el7.x86_64 cyrus-sasl-md5-2.1.26-12.1.el7.x86_64 cyrus-sasl-plain-2.1.26-12.1.el7.x86_64 dbus-libs-1.6.12-5.el7.x86_64 krb5-libs-1.11.3-31.el7.x86_64 libiscsi-1.7.0-6.el7.x86_64 libuuid-2.23.2-6.el7.x86_64 nspr-4.10-3.el7.x86_64 nss-3.15.2-8.el7.x86_64 openssl-libs-1.0.1e-23.el7.x86_64
(gdb) bt
#0  0x00007f4fe8691e40 in ?? ()
#1  0x00007f4fe733f4b8 in qemu_chr_be_can_write (s=<optimized out>) at qemu-char.c:161
#2  pty_chr_read_poll (opaque=<optimized out>) at qemu-char.c:1042
#3  0x00007f4fe7340fb2 in io_watch_poll_prepare (source=0x7f4fe8464d70, timeout_=timeout_@entry=0x7fffb6a2d664) at qemu-char.c:593
#4  0x00007f4fe689d79d in g_main_context_prepare (context=context@entry=0x7f4fe8464a00, 
    priority=priority@entry=0x7f4fe7c9eb80 <max_priority>) at gmain.c:3328
#5  0x00007f4fe731adb6 in glib_pollfds_fill (cur_timeout=<synthetic pointer>) at main-loop.c:163
#6  os_host_main_loop_wait (timeout=1000) at main-loop.c:198
#7  main_loop_wait (nonblocking=<optimized out>) at main-loop.c:464
#8  0x00007f4fe721b609 in main_loop () at vl.c:2029
#9  main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4419

Hi Gerd,
 Would please help check above bt and clarify if I reproduced this issue? Thanks very much.

Stack trace looks unrelated.  Doesn't reproduce here (qemu-kvm-1.5.3-19.el7.x86_64).  Can you retest with latest qemu-kvm please?
In case it still happens: please install the missing debuginfos, so we get symbol names instead of the question marks for stackframe #0?

Reproduced on qemu-kvm-1.5.1-2.el7.x86_64.rpm. qemu-kvm coredumped once hot removing pty backend.

(gdb) bt
#0  0x00007f0f049752b0 in g_io_channel_unix_get_fd () from /lib64/libglib-2.0.so.0
#1  0x00007f0f053d9594 in pty_chr_update_read_handler (chr=0x7f0f071e88a0) at qemu-char.c:1076
#2  0x00007f0f053d9625 in pty_chr_timer (opaque=<optimized out>) at qemu-char.c:996
#3  0x00007f0f04935963 in g_timeout_dispatch () from /lib64/libglib-2.0.so.0
#4  0x00007f0f04934e06 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#5  0x00007f0f053b1eba in glib_pollfds_poll () at main-loop.c:187
#6  os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:232
#7  main_loop_wait (nonblocking=<optimized out>) at main-loop.c:464
#8  0x00007f0f052b2609 in main_loop () at vl.c:2029
#9  main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4419

Verified on qemu-kvm-1.5.3-20.el7.x86_64.rpm. qemu-kvm worked well after hot removing pty backend.

CLI:
/usr/libexec/qemu-kvm -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0 -drive file=/var/lib/libvirt/images/test.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:93:80:0b,bus=pci.0 -chardev pty,id=channel1 -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=channel1,id=channel0,name=com.redhat.spice.0 -vga cirrus -vnc :1

Steps:
# nc -U /var/lib/libvirt/qemu/test.monitor 
# {"QMP": {"version": {"qemu": {"micro": 3, "minor": 5, "major": 1}, "package": " (qemu-kvm-1.5.3-20.el7)"}, "capabilities": []}}
# {"execute":"qmp_capabilities"}
# {"return": {}}
# {"timestamp": {"seconds": 1385979309, "microseconds": 163800}, "event": "NIC_RX_FILTER_CHANGED", "data": {"name": "net0", "path": "/machine/peripheral/net0/virtio-backend"}}
# {"timestamp": {"seconds": 1385979314, "microseconds": 195430}, "event": "VNC_CONNECTED", "data": {"server": {"auth": "none", "family": "ipv4", "service": "5901", "host": "0.0.0.0"}, "client": {"family": "ipv4", "service": "36090", "host": "127.0.0.1"}}}
# {"timestamp": {"seconds": 1385979314, "microseconds": 196227}, "event": "VNC_INITIALIZED", "data": {"server": {"auth": "none", "family": "ipv4", "service": "5901", "host": "0.0.0.0"}, "client": {"family": "ipv4", "service": "36090", "host": "127.0.0.1"}}}
# {"execute":"device_del","arguments":{"id":"channel0"}}
# {"timestamp": {"seconds": 1385979333, "microseconds": 459081}, "event": "DEVICE_DELETED", "data": {"device": "channel0", "path": "/machine/peripheral/channel0"}}
# {"return": {}}
# {"execute":"chardev-remove","arguments":{"id":"channel1"}}
# {"return": {}}



As per above, this issue has been fixed.

(In reply to Gerd Hoffmann from comment #12)
> Stack trace looks unrelated.  Doesn't reproduce here
> (qemu-kvm-1.5.3-19.el7.x86_64).  Can you retest with latest qemu-kvm please?
> In case it still happens: please install the missing debuginfos, so we get
> symbol names instead of the question marks for stackframe #0?

Cannot reproduce with qemu-kvm-1.5.3-20.el7.x86_64.rpm, either.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.