[Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Leonardo Soares Müller]

With QEMU version 3.1.50 (v3.1.0-1218-gad7a21e812-dirty) (commit
ad7a21e81231ae64540310384fb0f87ac8758b02) on Xubuntu 18.04 host, a KDE
Neon guest is crashing on boot. The QEMU command line is:

gdb -q -ex "set pagination off" -ex "set print thread-events off" -ex
"handle SIGUSR1 nostop nopass noprint" -ex "run" --args
qemu-system-x86_64 -accel kvm -cpu host -smp cores=2,threads=1 -m 2048
-hda neonbroken.qcow2 -cdrom
~/Downloads/neon-useredition-20190124-0530-amd64.iso -device
qxl-vga,xres=1366,yres=768,addr=2 -display gtk,gl=on -monitor vc -serial
vc -device qemu-xhci,addr=3 -netdev user,id=net0 -device
e1000,netdev=net0,addr=4 -bios /usr/share/ovmf/OVMF.fd

The crash is happening pretty frequently but not 100% of the times.
Using virtio-vga instead of qxl-vga it's possible to use the guest
normally. Before the crash there are some graphical artifacts on guest
screen, they can be seen at https://i.imgur.com/rfTmmJ0.png

On terminal QEMU prints the following messages:

$ qemu-system-x86_64 -accel kvm -cpu host -smp cores=2,threads=1 -m 2048
-hda neonbroken.qcow2 -cdrom
~/Downloads/neon-useredition-20190124-0530-amd64.iso -device
qxl-vga,xres=1366,yres=768,addr=2 -display gtk,gl=on -monitor vc -serial
vc -device qemu-xhci,addr=3 -netdev user,id=net0 -device
e1000,netdev=net0,addr=4 -bios /usr/share/ovmf/OVMF.fd

(qemu-system-x86_64:11683): Gtk-WARNING **: 18:18:34.797: Theme parsing
error: gtk.css:47:15: negative values are not allowed.
id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0,
delta 0
id 1, group 1, virt start 7ff31fe00000, virt end 7ff323dfe000,
generation 0, delta 7ff31fe00000
id 2, group 1, virt start 7ff31bc00000, virt end 7ff31fc00000,
generation 0, delta 7ff31bc00000

(qemu:11683): Spice-CRITICAL **: 18:39:40.747:
memslot.c:111:memslot_get_virt: slot_id 255 too big, addr=ff000000ff000000
Abortado (imagem do núcleo gravada)

Here is the backtrace:

(gdb) bt
#0  0x00007ffff0373e97 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff0375801 in __GI_abort () at abort.c:79
#2  0x00007ffff1171cc9 in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#3  0x00007ffff11373b8 in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#4  0x00007ffff11407d0 in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#5  0x00007ffff1140a76 in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#6  0x00007ffff11419a1 in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#7  0x00007ffff11543cd in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#8  0x00007ffff1152d21 in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#9  0x00007ffff11534bf in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#10 0x00007ffff11214f1 in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#11 0x00007ffff1127d7b in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#12 0x00007ffff47931f5 in g_main_context_dispatch () at
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff47935c0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff47938d2 in g_main_loop_run () at
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007ffff1153b3a in  () at
/usr/lib/x86_64-linux-gnu/libspice-server.so.1
#16 0x00007ffff072d6db in start_thread (arg=0x7fff3602c700) at
pthread_create.c:463

Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Dr. David Alan Gilbert]

* Leonardo Soares Müller (leozinho29_eu@hotmail.com) wrote:
> With QEMU version 3.1.50 (v3.1.0-1218-gad7a21e812-dirty) (commit
> ad7a21e81231ae64540310384fb0f87ac8758b02) on Xubuntu 18.04 host, a KDE
> Neon guest is crashing on boot. The QEMU command line is:
> 
> gdb -q -ex "set pagination off" -ex "set print thread-events off" -ex
> "handle SIGUSR1 nostop nopass noprint" -ex "run" --args
> qemu-system-x86_64 -accel kvm -cpu host -smp cores=2,threads=1 -m 2048
> -hda neonbroken.qcow2 -cdrom
> ~/Downloads/neon-useredition-20190124-0530-amd64.iso -device
> qxl-vga,xres=1366,yres=768,addr=2 -display gtk,gl=on -monitor vc -serial
> vc -device qemu-xhci,addr=3 -netdev user,id=net0 -device
> e1000,netdev=net0,addr=4 -bios /usr/share/ovmf/OVMF.fd
> 
> The crash is happening pretty frequently but not 100% of the times.
> Using virtio-vga instead of qxl-vga it's possible to use the guest
> normally. Before the crash there are some graphical artifacts on guest
> screen, they can be seen at https://i.imgur.com/rfTmmJ0.png
> 
> On terminal QEMU prints the following messages:
> 
> $ qemu-system-x86_64 -accel kvm -cpu host -smp cores=2,threads=1 -m 2048
> -hda neonbroken.qcow2 -cdrom
> ~/Downloads/neon-useredition-20190124-0530-amd64.iso -device
> qxl-vga,xres=1366,yres=768,addr=2 -display gtk,gl=on -monitor vc -serial
> vc -device qemu-xhci,addr=3 -netdev user,id=net0 -device
> e1000,netdev=net0,addr=4 -bios /usr/share/ovmf/OVMF.fd
> 
> (qemu-system-x86_64:11683): Gtk-WARNING **: 18:18:34.797: Theme parsing
> error: gtk.css:47:15: negative values are not allowed.
> id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0,
> delta 0
> id 1, group 1, virt start 7ff31fe00000, virt end 7ff323dfe000,
> generation 0, delta 7ff31fe00000
> id 2, group 1, virt start 7ff31bc00000, virt end 7ff31fc00000,
> generation 0, delta 7ff31bc00000
> 
> (qemu:11683): Spice-CRITICAL **: 18:39:40.747:
> memslot.c:111:memslot_get_virt: slot_id 255 too big, addr=ff000000ff000000

Thanks for the report,

Could you install the debug packages of libspice-server on your system
so that the backtrace you get has symbols?

Dave

> Abortado (imagem do núcleo gravada)
> 
> Here is the backtrace:
> 
> (gdb) bt
> #0  0x00007ffff0373e97 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x00007ffff0375801 in __GI_abort () at abort.c:79
> #2  0x00007ffff1171cc9 in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #3  0x00007ffff11373b8 in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #4  0x00007ffff11407d0 in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #5  0x00007ffff1140a76 in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #6  0x00007ffff11419a1 in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #7  0x00007ffff11543cd in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #8  0x00007ffff1152d21 in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #9  0x00007ffff11534bf in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #10 0x00007ffff11214f1 in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #11 0x00007ffff1127d7b in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #12 0x00007ffff47931f5 in g_main_context_dispatch () at
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #13 0x00007ffff47935c0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #14 0x00007ffff47938d2 in g_main_loop_run () at
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #15 0x00007ffff1153b3a in  () at
> /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> #16 0x00007ffff072d6db in start_thread (arg=0x7fff3602c700) at
> pthread_create.c:463
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Leonardo Soares Müller]

Here is the backtrace with the debug symbols added:

(gdb) bt
#0  0x00007ffff0373e97 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff0375801 in __GI_abort () at abort.c:79
#2  0x00007ffff1171cc9 in spice_logv (log_domain=0x7ffff11dc9f5 "Spice",
args=0x7fff36028cb0, format=0x7ffff11e3c5b "slot_id %d too big,
addr=%lx", function=0x7ffff11e3d90 <__FUNCTION__.15594>
"memslot_get_virt", strloc=0x7ffff11e3c78 "memslot.c:111",
log_level=G_LOG_LEVEL_CRITICAL) at log.c:183
#3  0x00007ffff1171cc9 in spice_log
(log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
strloc=strloc@entry=0x7ffff11e3c78 "memslot.c:111",
function=function@entry=0x7ffff11e3d90 <__FUNCTION__.15594>
"memslot_get_virt", format=format@entry=0x7ffff11e3c5b "slot_id %d too
big, addr=%lx") at log.c:196
#4  0x00007ffff11373b8 in memslot_get_virt
(info=info@entry=0x5555579b8630, addr=addr@entry=18374686483949813760,
add_size=add_size@entry=10, group_id=group_id@entry=1,
error=error@entry=0x7fff36028e08)
    at memslot.c:111
#5  0x00007ffff11407d0 in red_get_image
(slots=slots@entry=0x5555579b8630, group_id=group_id@entry=1,
addr=<optimized out>, flags=flags@entry=0, is_mask=is_mask@entry=false)
at red-parse-qxl.c:512
#6  0x00007ffff1140a76 in red_get_copy_ptr
(slots=slots@entry=0x5555579b8630, group_id=group_id@entry=1,
red=red@entry=0x7fff1409f5f0, qxl=0x7fff1fe0107b, flags=flags@entry=0)
at red-parse-qxl.c:680
#7  0x00007ffff11419a1 in red_get_native_drawable (flags=<optimized
out>, addr=<optimized out>, red=<optimized out>, group_id=<optimized
out>, slots=<optimized out>) at red-parse-qxl.c:1072
#8  0x00007ffff11419a1 in red_get_drawable
(slots=slots@entry=0x5555579b8630, group_id=1,
red=red@entry=0x7fff1409f550, addr=<optimized out>, flags=0) at
red-parse-qxl.c:1206
#9  0x00007ffff11543cd in red_process_display (worker=0x5555579b85a0,
ring_is_empty=0x7fff36028f9c) at red-worker.c:224
#10 0x00007ffff1152d21 in flush_commands
(worker=worker@entry=0x5555579b85a0, red_channel=0x5555579b4a10,
process=process@entry=0x7ffff1154220 <red_process_display>) at
red-worker.c:315
#11 0x00007ffff1152e58 in flush_display_commands
(worker=worker@entry=0x5555579b85a0) at red-worker.c:352
#12 0x00007ffff11534bf in flush_all_qxl_commands (worker=0x5555579b85a0)
at red-worker.c:367
#13 0x00007ffff11534bf in destroy_primary_surface
(worker=0x5555579b85a0, surface_id=0) at red-worker.c:558
#14 0x00007ffff11214f1 in dispatcher_handle_single_read
(dispatcher=0x555556a0c1c0) at dispatcher.c:284
#15 0x00007ffff11214f1 in dispatcher_handle_recv_read
(dispatcher=0x555556a0c1c0) at dispatcher.c:304
#16 0x00007ffff1127d7b in watch_func (source=<optimized out>,
condition=<optimized out>, data=0x5555579b8780) at event-loop.c:128
#17 0x00007ffff47931f5 in g_main_context_dispatch () at
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff47935c0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff47938d2 in g_main_loop_run () at
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007ffff1153b3a in red_worker_main (arg=0x5555579b85a0) at
red-worker.c:1372
#21 0x00007ffff072d6db in start_thread (arg=0x7fff3602c700) at
pthread_create.c:463
#22 0x00007ffff045688f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Às 10:13 de 28/01/2019, Dr. David Alan Gilbert escreveu:
> 
> Thanks for the report,
> 
> Could you install the debug packages of libspice-server on your system
> so that the backtrace you get has symbols?
> 
> Dave
> 

Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Dr. David Alan Gilbert]

* Leonardo Soares Müller (leozinho29_eu@hotmail.com) wrote:
> Here is the backtrace with the debug symbols added:

OK, great;  can can you confirm the version of the spice packages
on both the guest and host, and the kernel on the guest.

Dave

> (gdb) bt
> #0  0x00007ffff0373e97 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x00007ffff0375801 in __GI_abort () at abort.c:79
> #2  0x00007ffff1171cc9 in spice_logv (log_domain=0x7ffff11dc9f5 "Spice",
> args=0x7fff36028cb0, format=0x7ffff11e3c5b "slot_id %d too big,
> addr=%lx", function=0x7ffff11e3d90 <__FUNCTION__.15594>
> "memslot_get_virt", strloc=0x7ffff11e3c78 "memslot.c:111",
> log_level=G_LOG_LEVEL_CRITICAL) at log.c:183
> #3  0x00007ffff1171cc9 in spice_log
> (log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
> strloc=strloc@entry=0x7ffff11e3c78 "memslot.c:111",
> function=function@entry=0x7ffff11e3d90 <__FUNCTION__.15594>
> "memslot_get_virt", format=format@entry=0x7ffff11e3c5b "slot_id %d too
> big, addr=%lx") at log.c:196
> #4  0x00007ffff11373b8 in memslot_get_virt
> (info=info@entry=0x5555579b8630, addr=addr@entry=18374686483949813760,
> add_size=add_size@entry=10, group_id=group_id@entry=1,
> error=error@entry=0x7fff36028e08)
>     at memslot.c:111
> #5  0x00007ffff11407d0 in red_get_image
> (slots=slots@entry=0x5555579b8630, group_id=group_id@entry=1,
> addr=<optimized out>, flags=flags@entry=0, is_mask=is_mask@entry=false)
> at red-parse-qxl.c:512
> #6  0x00007ffff1140a76 in red_get_copy_ptr
> (slots=slots@entry=0x5555579b8630, group_id=group_id@entry=1,
> red=red@entry=0x7fff1409f5f0, qxl=0x7fff1fe0107b, flags=flags@entry=0)
> at red-parse-qxl.c:680
> #7  0x00007ffff11419a1 in red_get_native_drawable (flags=<optimized
> out>, addr=<optimized out>, red=<optimized out>, group_id=<optimized
> out>, slots=<optimized out>) at red-parse-qxl.c:1072
> #8  0x00007ffff11419a1 in red_get_drawable
> (slots=slots@entry=0x5555579b8630, group_id=1,
> red=red@entry=0x7fff1409f550, addr=<optimized out>, flags=0) at
> red-parse-qxl.c:1206
> #9  0x00007ffff11543cd in red_process_display (worker=0x5555579b85a0,
> ring_is_empty=0x7fff36028f9c) at red-worker.c:224
> #10 0x00007ffff1152d21 in flush_commands
> (worker=worker@entry=0x5555579b85a0, red_channel=0x5555579b4a10,
> process=process@entry=0x7ffff1154220 <red_process_display>) at
> red-worker.c:315
> #11 0x00007ffff1152e58 in flush_display_commands
> (worker=worker@entry=0x5555579b85a0) at red-worker.c:352
> #12 0x00007ffff11534bf in flush_all_qxl_commands (worker=0x5555579b85a0)
> at red-worker.c:367
> #13 0x00007ffff11534bf in destroy_primary_surface
> (worker=0x5555579b85a0, surface_id=0) at red-worker.c:558
> #14 0x00007ffff11214f1 in dispatcher_handle_single_read
> (dispatcher=0x555556a0c1c0) at dispatcher.c:284
> #15 0x00007ffff11214f1 in dispatcher_handle_recv_read
> (dispatcher=0x555556a0c1c0) at dispatcher.c:304
> #16 0x00007ffff1127d7b in watch_func (source=<optimized out>,
> condition=<optimized out>, data=0x5555579b8780) at event-loop.c:128
> #17 0x00007ffff47931f5 in g_main_context_dispatch () at
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #18 0x00007ffff47935c0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #19 0x00007ffff47938d2 in g_main_loop_run () at
> /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #20 0x00007ffff1153b3a in red_worker_main (arg=0x5555579b85a0) at
> red-worker.c:1372
> #21 0x00007ffff072d6db in start_thread (arg=0x7fff3602c700) at
> pthread_create.c:463
> #22 0x00007ffff045688f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> 
> 
> Às 10:13 de 28/01/2019, Dr. David Alan Gilbert escreveu:
> > 
> > Thanks for the report,
> > 
> > Could you install the debug packages of libspice-server on your system
> > so that the backtrace you get has symbols?
> > 
> > Dave
> > 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Leonardo Soares Müller]

libspice-server1 on host: 0.14.0-1ubuntu2.2
spice-vdagent (the only package) on guest: 0.17.0-1ubuntu2
Guest kernel version: 4.15.0-44-generic

> 
> OK, great;  can can you confirm the version of the spice packages
> on both the guest and host, and the kernel on the guest.
> 
> Dave
> 
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 

Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Dr. David Alan Gilbert]

* Leonardo Soares Müller (leozinho29_eu@hotmail.com) wrote:
> libspice-server1 on host: 0.14.0-1ubuntu2.2
> spice-vdagent (the only package) on guest: 0.17.0-1ubuntu2
> Guest kernel version: 4.15.0-44-generic

Hmm, I'm also getting a crash, but I think it's very different from
yours:

./x86_64-softmmu/qemu-system-x86_64 -M pc,accel=kvm -smp 3 -m 8G -cdrom /home/vmimages/neon-useredition-current.iso -drive if=virtio,file=/home/vmimages/kde-neon.qcow2 -vga qxl

kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device
Aborted (core dumped)

#2  0x0000555555893ee6 in kvm_mem_ioeventfd_add (listener=<optimized out>, section=0x7fffdbffb9d0, match_data=<optimized out>, data=0, e=<optimized out>)
    at /home/dgilbert/git/qemu/accel/kvm/kvm-all.c:866
#3  0x000055555588123d in address_space_add_del_ioeventfds
    (fds_old_nb=0, fds_old=0x0, fds_new_nb=1, fds_new=0x7fffd0944570, as=0x5555563bbea0 <address_space_memory>) at /home/dgilbert/git/qemu/memory.c:793
#4  0x000055555588123d in address_space_update_ioeventfds (as=as@entry=0x5555563bbea0 <address_space_memory>) at /home/dgilbert/git/qemu/memory.c:843
#5  0x00005555558816c8 in memory_region_transaction_commit () at /home/dgilbert/git/qemu/memory.c:1087
#6  0x00005555558816c8 in memory_region_transaction_commit () at /home/dgilbert/git/qemu/memory.c:1071
#7  0x0000555555aab425 in pci_update_mappings (d=d@entry=0x555557617ce0) at /home/dgilbert/git/qemu/hw/pci/pci.c:1357
#8  0x0000555555aaba89 in pci_default_write_config (d=d@entry=0x555557617ce0, addr=addr@entry=4, val_in=263, l=l@entry=2)
    at /home/dgilbert/git/qemu/hw/pci/pci.c:1413
#9  0x0000555555b216c1 in virtio_write_config (pci_dev=0x555557617ce0, address=4, val=<optimized out>, len=2)
    at /home/dgilbert/git/qemu/hw/virtio/virtio-pci.c:598
#10 0x0000555555ab26bf in pci_host_config_write_common (pci_dev=0x555557617ce0, addr=4, limit=<optimized out>, val=263, len=2)
    at /home/dgilbert/git/qemu/hw/pci/pci_host.c:87
#11 0x000055555587f721 in memory_region_write_accessor
    (mr=0x555556a0bf80, addr=0, value=<optimized out>, size=2, shift=<optimized out>, mask=<optimized out>, attrs=...)
    at /home/dgilbert/git/qemu/memory.c:502
#12 0x000055555587d276 in access_with_adjusted_size
    (addr=addr@entry=0, value=value@entry=0x7fffdbffbce8, size=size@entry=2, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry=0x55555587f6a0 <memory_region_write_accessor>, mr=0x555556a0bf80, attrs=...) at /home/dgilbert/git/qemu/memory.c:568
#13 0x0000555555881bfc in memory_region_dispatch_write (mr=mr@entry=0x555556a0bf80, addr=0, data=<optimized out>, size=2, attrs=attrs@entry=...)
    at /home/dgilbert/git/qemu/memory.c:1499
#14 0x0000555555828923 in flatview_write_continue
    (fv=fv@entry=0x7fffd0847c00, addr=addr@entry=3324, attrs=..., buf=buf@entry=0x7ffff7fc5000 "\a\001", len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=0x555556a0bf80) at /home/dgilbert/git/qemu/exec.c:3247
#15 0x0000555555828b49 in flatview_write (fv=0x7fffd0847c00, addr=3324, attrs=..., buf=0x7ffff7fc5000 "\a\001", len=2)
    at /home/dgilbert/git/qemu/exec.c:3286
#16 0x000055555582cc7f in address_space_write (as=<optimized out>, addr=addr@entry=3324, attrs=..., buf=<optimized out>, len=len@entry=2)
    at /home/dgilbert/git/qemu/exec.c:3376
#17 0x000055555582cd0a in address_space_rw (as=<optimized out>, addr=addr@entry=3324, attrs=..., 
    attrs@entry=..., buf=<optimized out>, len=len@entry=2, is_write=is_write@entry=true) at /home/dgilbert/git/qemu/exec.c:3387
#18 0x0000555555894e45 in kvm_handle_io (count=1, size=2, direction=<optimized out>, data=<optimized out>, attrs=..., port=3324)
    at /home/dgilbert/git/qemu/accel/kvm/kvm-all.c:1775
#19 0x0000555555894e45 in kvm_cpu_exec (cpu=cpu@entry=0x55555670f6f0) at /home/dgilbert/git/qemu/accel/kvm/kvm-all.c:2021
#20 0x000055555586a6be in qemu_kvm_cpu_thread_fn (arg=0x55555670f6f0) at /home/dgilbert/git/qemu/cpus.c:1281
#21 0x000055555586a6be in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x55555670f6f0) at /home/dgilbert/git/qemu/cpus.c:1254
#22 0x0000555555ca0e7a in qemu_thread_start (args=<optimized out>) at /home/dgilbert/git/qemu/util/qemu-thread-posix.c:502
#23 0x00007ffff536258e in start_thread () at /lib64/libpthread.so.0

(gdb) p section->offset_within_address_space
$3 = 4273991680
(gdb) p/x section->offset_within_address_space
$4 = 0xfebff000
(gdb) p section
$5 = (MemoryRegionSection *) 0x7fffdbffb9d0
(gdb) p *section
$6 = {mr = 0x0, fv = 0x7fffd08fe680, offset_within_region = 0, size = 0, offset_within_address_space = 4273991680, readonly = false, nonvolatile = false}

Dave

> > 
> > OK, great;  can can you confirm the version of the spice packages
> > on both the guest and host, and the kernel on the guest.
> > 
> > Dave
> > 
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Leonardo Soares Müller]

I can confirm this, KDE Neon using the command line similar to yours
crashes QEMU to me too. I will test with Mageia 7 later to see if it
behaves differently.

But this is a completely different crash. This crash is happening
earlier, what I reported first is a crash when the login screen should
load, this is happening earlier on boot.

The command line I used this time:

qemu-system-x86_64 -M pc,accel=kvm -smp 3 -m 4G -drive
if=virtio,file=neonbroken.qcow2 -vga qxl -bios /usr/share/ovmf/OVMF.fd

The backtrace:

(gdb) bt
#0  0x00007ffff0371e97 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff0373801 in __GI_abort () at abort.c:79
#2  0x000055555589eac9 in kvm_mem_ioeventfd_add
(listener=0x555556a1fdc8, section=0x7fffc7ffba90, match_data=false,
data=0, e=0x5555578c7fc8) at
/home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:866
#3  0x000055555588300a in address_space_add_del_ioeventfds
(as=0x5555567e5a00 <address_space_memory>, fds_new=0x7fffbc000d30,
fds_new_nb=1, fds_old=0x0, fds_old_nb=0) at
/home/usuario/Documentos/qemu/memory.c:793
#4  0x00005555558832f4 in address_space_update_ioeventfds
(as=0x5555567e5a00 <address_space_memory>) at
/home/usuario/Documentos/qemu/memory.c:843
#5  0x000055555588415b in memory_region_transaction_commit () at
/home/usuario/Documentos/qemu/memory.c:1094
#6  0x00005555558871c8 in memory_region_add_eventfd (mr=0x5555578b6420,
addr=0, size=0, match_data=false, data=0, e=0x5555578c7fc8) at
/home/usuario/Documentos/qemu/memory.c:2303
#7  0x0000555555c26cd0 in virtio_pci_ioeventfd_assign (d=0x5555578b5750,
notifier=0x5555578c7fc8, n=0, assign=true) at hw/virtio/virtio-pci.c:243
#8  0x0000555555c24dd5 in virtio_bus_set_host_notifier
(bus=0x5555578bd848, n=0, assign=true) at hw/virtio/virtio-bus.c:283
#9  0x00005555558ce648 in virtio_blk_data_plane_start
(vdev=0x5555578bd8c0) at
/home/usuario/Documentos/qemu/hw/block/dataplane/virtio-blk.c:200
#10 0x0000555555c24af2 in virtio_bus_start_ioeventfd
(bus=0x5555578bd848) at hw/virtio/virtio-bus.c:223
#11 0x0000555555c26e57 in virtio_pci_start_ioeventfd
(proxy=0x5555578b5750) at hw/virtio/virtio-pci.c:282
#12 0x0000555555c29285 in virtio_pci_common_write
(opaque=0x5555578b5750, addr=20, val=15, size=1) at
hw/virtio/virtio-pci.c:1233
#13 0x0000555555881ebd in memory_region_write_accessor
(mr=0x5555578b6120, addr=20, value=0x7fffc7ffbf38, size=1, shift=0,
mask=255, attrs=...) at /home/usuario/Documentos/qemu/memory.c:502
#14 0x00005555558820cd in access_with_adjusted_size (addr=20,
value=0x7fffc7ffbf38, size=1, access_size_min=1, access_size_max=4,
access_fn=0x555555881dd4 <memory_region_write_accessor>,
mr=0x5555578b6120, attrs=...) at /home/usuario/Documentos/qemu/memory.c:568
#15 0x0000555555885100 in memory_region_dispatch_write
(mr=0x5555578b6120, addr=20, data=15, size=1, attrs=...) at
/home/usuario/Documentos/qemu/memory.c:1499
#16 0x000055555581bca9 in flatview_write_continue (fv=0x7fffcc50f4f0,
addr=34359738388, attrs=..., buf=0x7ffff7fee028 "\017", len=1, addr1=20,
l=1, mr=0x5555578b6120) at /home/usuario/Documentos/qemu/exec.c:3234
#17 0x000055555581bdf3 in flatview_write (fv=0x7fffcc50f4f0,
addr=34359738388, attrs=..., buf=0x7ffff7fee028 "\017", len=1) at
/home/usuario/Documentos/qemu/exec.c:3273
#18 0x000055555581c0f9 in address_space_write (as=0x5555567e5a00
<address_space_memory>, addr=34359738388, attrs=..., buf=0x7ffff7fee028
"\017", len=1) at /home/usuario/Documentos/qemu/exec.c:3363
#19 0x000055555581c14a in address_space_rw (as=0x5555567e5a00
<address_space_memory>, addr=34359738388, attrs=..., buf=0x7ffff7fee028
"\017", len=1, is_write=true) at /home/usuario/Documentos/qemu/exec.c:3374
#20 0x00005555558a146f in kvm_cpu_exec (cpu=0x555556afe140) at
/home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:2031
#21 0x0000555555865a3e in qemu_kvm_cpu_thread_fn (arg=0x555556afe140) at
/home/usuario/Documentos/qemu/cpus.c:1281
#22 0x0000555555e1ba02 in qemu_thread_start (args=0x555556b20440) at
util/qemu-thread-posix.c:502
#23 0x00007ffff072b6db in start_thread (arg=0x7fffc7fff700) at
pthread_create.c:463
#24 0x00007ffff045488f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Às 11:36 de 01/02/2019, Dr. David Alan Gilbert escreveu:
> 
> Hmm, I'm also getting a crash, but I think it's very different from
> yours:
> 
> ./x86_64-softmmu/qemu-system-x86_64 -M pc,accel=kvm -smp 3 -m 8G -cdrom /home/vmimages/neon-useredition-current.iso -drive if=virtio,file=/home/vmimages/kde-neon.qcow2 -vga qxl
> 
> kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device
> Aborted (core dumped)
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 

Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Leonardo Soares Müller]

Mageia 7 guest is crashing too. The command line:

qemu-system-x86_64 \
-name "Mageia 7" -k pt-br -nodefaults -accel kvm -cpu host -smp
cores=2,threads=1 -m 1G \
-device qxl-vga,xres=1366,yres=768 \
-device qemu-xhci,id=xhcihub -device usb-audio,id=usbaudio,buffer=6144  \
-device usb-tablet,id=usbtablet -bios /usr/share/ovmf/OVMF.fd -display
gtk,gl=on \
-drive if=virtio,file=mageia7.qcow2 \
-monitor vc -serial vc -cdrom "Mageia-7-beta1-Live-Xfce-x86_64.iso" \
-machine kernel_irqchip=on -global PIIX4_PM.disable_s3=1 -global
PIIX4_PM.disable_s4=1 -M pc,usb=true \
-netdev user,id=net0 -device e1000,netdev=net0,addr=8

It seems that:

-drive if=virtio,file=

is the cause of this. Replacing it with -hda makes the Mageia 7 guest
work normally. KDE Neon guest still crashes because of the other problem.

(gdb) bt
#0  0x00007ffff0371e97 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff0373801 in __GI_abort () at abort.c:79
#2  0x000055555589eac9 in kvm_mem_ioeventfd_add
(listener=0x555556b4ffd8, section=0x7fffcdf23a90, match_data=false,
data=0, e=0x555557b51658) at
/home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:866
#3  0x000055555588300a in address_space_add_del_ioeventfds
(as=0x5555567e5a00 <address_space_memory>, fds_new=0x7fffc4560fc0,
fds_new_nb=1, fds_old=0x0, fds_old_nb=0) at
/home/usuario/Documentos/qemu/memory.c:793
#4  0x00005555558832f4 in address_space_update_ioeventfds
(as=0x5555567e5a00 <address_space_memory>) at
/home/usuario/Documentos/qemu/memory.c:843
#5  0x000055555588415b in memory_region_transaction_commit () at
/home/usuario/Documentos/qemu/memory.c:1094
#6  0x00005555558871c8 in memory_region_add_eventfd (mr=0x555557b3fa00,
addr=0, size=0, match_data=false, data=0, e=0x555557b51658) at
/home/usuario/Documentos/qemu/memory.c:2303
#7  0x0000555555c26cd0 in virtio_pci_ioeventfd_assign (d=0x555557b3ed30,
notifier=0x555557b51658, n=0, assign=true) at hw/virtio/virtio-pci.c:243
#8  0x0000555555c24dd5 in virtio_bus_set_host_notifier
(bus=0x555557b46e28, n=0, assign=true) at hw/virtio/virtio-bus.c:283
#9  0x00005555558ce648 in virtio_blk_data_plane_start
(vdev=0x555557b46ea0) at
/home/usuario/Documentos/qemu/hw/block/dataplane/virtio-blk.c:200
#10 0x0000555555c24af2 in virtio_bus_start_ioeventfd
(bus=0x555557b46e28) at hw/virtio/virtio-bus.c:223
#11 0x0000555555c26e57 in virtio_pci_start_ioeventfd
(proxy=0x555557b3ed30) at hw/virtio/virtio-pci.c:282
#12 0x0000555555c29285 in virtio_pci_common_write
(opaque=0x555557b3ed30, addr=20, val=15, size=1) at
hw/virtio/virtio-pci.c:1233
#13 0x0000555555881ebd in memory_region_write_accessor
(mr=0x555557b3f700, addr=20, value=0x7fffcdf23f38, size=1, shift=0,
mask=255, attrs=...) at /home/usuario/Documentos/qemu/memory.c:502
#14 0x00005555558820cd in access_with_adjusted_size (addr=20,
value=0x7fffcdf23f38, size=1, access_size_min=1, access_size_max=4,
access_fn=
    0x555555881dd4 <memory_region_write_accessor>, mr=0x555557b3f700,
attrs=...) at /home/usuario/Documentos/qemu/memory.c:568
#15 0x0000555555885100 in memory_region_dispatch_write
(mr=0x555557b3f700, addr=20, data=15, size=1, attrs=...) at
/home/usuario/Documentos/qemu/memory.c:1499
#16 0x000055555581bca9 in flatview_write_continue (fv=0x7fffb8000fc0,
addr=34644951060, attrs=..., buf=0x7ffff7ff4028 <error: Não é possível
acessar a memória no endereço 0x7ffff7ff4028>, len=1, addr1=20, l=1,
mr=0x555557b3f700) at /home/usuario/Documentos/qemu/exec.c:3234
#17 0x000055555581bdf3 in flatview_write (fv=0x7fffb8000fc0,
addr=34644951060, attrs=..., buf=0x7ffff7ff4028 <error: Não é possível
acessar a memória no endereço 0x7ffff7ff4028>, len=1)
    at /home/usuario/Documentos/qemu/exec.c:3273
#18 0x000055555581c0f9 in address_space_write (as=0x5555567e5a00
<address_space_memory>, addr=34644951060, attrs=..., buf=0x7ffff7ff4028
<error: Não é possível acessar a memória no endereço 0x7ffff7ff4028>,
len=1) at /home/usuario/Documentos/qemu/exec.c:3363
#19 0x000055555581c14a in address_space_rw (as=0x5555567e5a00
<address_space_memory>, addr=34644951060, attrs=..., buf=0x7ffff7ff4028
<error: Não é possível acessar a memória no endereço 0x7ffff7ff4028>,
len=1, is_write=true) at /home/usuario/Documentos/qemu/exec.c:3374
#20 0x00005555558a146f in kvm_cpu_exec (cpu=0x555556bcc410) at
/home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:2031
#21 0x0000555555865a3e in qemu_kvm_cpu_thread_fn (arg=0x555556bcc410) at
/home/usuario/Documentos/qemu/cpus.c:1281
#22 0x0000555555e1ba02 in qemu_thread_start (args=0x555556bedaa0) at
util/qemu-thread-posix.c:502
#23 0x00007ffff072b6db in start_thread (arg=0x7fffcdf27700) at
pthread_create.c:463
#24 0x00007ffff045488f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Dr. David Alan Gilbert]

* Leonardo Soares Müller (leozinho29_eu@hotmail.com) wrote:
> I can confirm this, KDE Neon using the command line similar to yours
> crashes QEMU to me too. I will test with Mageia 7 later to see if it
> behaves differently.
> 
> But this is a completely different crash. This crash is happening
> earlier, what I reported first is a crash when the login screen should
> load, this is happening earlier on boot.
> 
> The command line I used this time:
> 
> qemu-system-x86_64 -M pc,accel=kvm -smp 3 -m 4G -drive
> if=virtio,file=neonbroken.qcow2 -vga qxl -bios /usr/share/ovmf/OVMF.fd

Right yes; as you say with hda it's fine;  I've pointed Paolo at
this one.

As for the original crash; I can't reproduce it here (On Fedora 29,
head qemu):
./x86_64-softmmu/qemu-system-x86_64 -cpu host  -M pc,accel=kvm -smp 3 -m 8G -drive if=ide,file=/home/vmimages/kde-neon.qcow2 -display gtk,gl=on -device qemu-xhci,addr=3 -device qxl-vga,xres=1366,yres=768,addr=4 -bios /usr/share/OVMF/OVMF_CODE.fd

Dave

> The backtrace:
> 
> (gdb) bt
> #0  0x00007ffff0371e97 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x00007ffff0373801 in __GI_abort () at abort.c:79
> #2  0x000055555589eac9 in kvm_mem_ioeventfd_add
> (listener=0x555556a1fdc8, section=0x7fffc7ffba90, match_data=false,
> data=0, e=0x5555578c7fc8) at
> /home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:866
> #3  0x000055555588300a in address_space_add_del_ioeventfds
> (as=0x5555567e5a00 <address_space_memory>, fds_new=0x7fffbc000d30,
> fds_new_nb=1, fds_old=0x0, fds_old_nb=0) at
> /home/usuario/Documentos/qemu/memory.c:793
> #4  0x00005555558832f4 in address_space_update_ioeventfds
> (as=0x5555567e5a00 <address_space_memory>) at
> /home/usuario/Documentos/qemu/memory.c:843
> #5  0x000055555588415b in memory_region_transaction_commit () at
> /home/usuario/Documentos/qemu/memory.c:1094
> #6  0x00005555558871c8 in memory_region_add_eventfd (mr=0x5555578b6420,
> addr=0, size=0, match_data=false, data=0, e=0x5555578c7fc8) at
> /home/usuario/Documentos/qemu/memory.c:2303
> #7  0x0000555555c26cd0 in virtio_pci_ioeventfd_assign (d=0x5555578b5750,
> notifier=0x5555578c7fc8, n=0, assign=true) at hw/virtio/virtio-pci.c:243
> #8  0x0000555555c24dd5 in virtio_bus_set_host_notifier
> (bus=0x5555578bd848, n=0, assign=true) at hw/virtio/virtio-bus.c:283
> #9  0x00005555558ce648 in virtio_blk_data_plane_start
> (vdev=0x5555578bd8c0) at
> /home/usuario/Documentos/qemu/hw/block/dataplane/virtio-blk.c:200
> #10 0x0000555555c24af2 in virtio_bus_start_ioeventfd
> (bus=0x5555578bd848) at hw/virtio/virtio-bus.c:223
> #11 0x0000555555c26e57 in virtio_pci_start_ioeventfd
> (proxy=0x5555578b5750) at hw/virtio/virtio-pci.c:282
> #12 0x0000555555c29285 in virtio_pci_common_write
> (opaque=0x5555578b5750, addr=20, val=15, size=1) at
> hw/virtio/virtio-pci.c:1233
> #13 0x0000555555881ebd in memory_region_write_accessor
> (mr=0x5555578b6120, addr=20, value=0x7fffc7ffbf38, size=1, shift=0,
> mask=255, attrs=...) at /home/usuario/Documentos/qemu/memory.c:502
> #14 0x00005555558820cd in access_with_adjusted_size (addr=20,
> value=0x7fffc7ffbf38, size=1, access_size_min=1, access_size_max=4,
> access_fn=0x555555881dd4 <memory_region_write_accessor>,
> mr=0x5555578b6120, attrs=...) at /home/usuario/Documentos/qemu/memory.c:568
> #15 0x0000555555885100 in memory_region_dispatch_write
> (mr=0x5555578b6120, addr=20, data=15, size=1, attrs=...) at
> /home/usuario/Documentos/qemu/memory.c:1499
> #16 0x000055555581bca9 in flatview_write_continue (fv=0x7fffcc50f4f0,
> addr=34359738388, attrs=..., buf=0x7ffff7fee028 "\017", len=1, addr1=20,
> l=1, mr=0x5555578b6120) at /home/usuario/Documentos/qemu/exec.c:3234
> #17 0x000055555581bdf3 in flatview_write (fv=0x7fffcc50f4f0,
> addr=34359738388, attrs=..., buf=0x7ffff7fee028 "\017", len=1) at
> /home/usuario/Documentos/qemu/exec.c:3273
> #18 0x000055555581c0f9 in address_space_write (as=0x5555567e5a00
> <address_space_memory>, addr=34359738388, attrs=..., buf=0x7ffff7fee028
> "\017", len=1) at /home/usuario/Documentos/qemu/exec.c:3363
> #19 0x000055555581c14a in address_space_rw (as=0x5555567e5a00
> <address_space_memory>, addr=34359738388, attrs=..., buf=0x7ffff7fee028
> "\017", len=1, is_write=true) at /home/usuario/Documentos/qemu/exec.c:3374
> #20 0x00005555558a146f in kvm_cpu_exec (cpu=0x555556afe140) at
> /home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:2031
> #21 0x0000555555865a3e in qemu_kvm_cpu_thread_fn (arg=0x555556afe140) at
> /home/usuario/Documentos/qemu/cpus.c:1281
> #22 0x0000555555e1ba02 in qemu_thread_start (args=0x555556b20440) at
> util/qemu-thread-posix.c:502
> #23 0x00007ffff072b6db in start_thread (arg=0x7fffc7fff700) at
> pthread_create.c:463
> #24 0x00007ffff045488f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> 
> 
> Às 11:36 de 01/02/2019, Dr. David Alan Gilbert escreveu:
> > 
> > Hmm, I'm also getting a crash, but I think it's very different from
> > yours:
> > 
> > ./x86_64-softmmu/qemu-system-x86_64 -M pc,accel=kvm -smp 3 -m 8G -cdrom /home/vmimages/neon-useredition-current.iso -drive if=virtio,file=/home/vmimages/kde-neon.qcow2 -vga qxl
> > 
> > kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device
> > Aborted (core dumped)
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Leonardo Soares Müller]

Thank you for testing this, the last update greatly improved the
situation. libspice-server1 updated, so I rebuilt QEMU. The
libspice-server1 0.14.0-1ubuntu2.4 change log is:

  * SECURITY UPDATE: off-by-one error in memslot_get_virt
    - debian/patches/CVE-2019-3813.patch: fix checks in server/memslot.c,
      add tests to server/tests/test-qxl-parsing.c.
    - CVE-2019-3813
  * debian/tests/automated-tests: fix incorrect test name, don't fail on
    build writing to stderr.

The errors on terminal are:

(qemu:11683): Spice-CRITICAL **: 18:39:40.747:
memslot.c:111:memslot_get_virt: slot_id 255 too big, addr=ff000000ff000000
Abortado (imagem do núcleo gravada)

The function that was changed with the last update seems to be the exact
same function that was causing the crash. Now the crash happens ONLY in
the first execution. All subsequent executions work correctly.

While the guest crashes on the first execution, it seems the guest file
system is resilient enough to suffer no damages from the crash on the
first boot and subsequent boots all seem perfect.

I installed the debug symbols for libglib-2.0 too, hopefully the
additional debug messages have some useful information. From the first
execution that crashes (gtk,gl=on and gtk had the same result):

qemu-system-x86_64 -accel kvm -cpu host -smp cores=2,threads=1 -m 2048
-hda neonbroken.qcow2 -device qxl-vga,xres=1366,yres=768,addr=2 -display
gtk,gl=on -monitor vc -serial vc -device qemu-xhci,addr=3 -netdev
user,id=net0 -device e1000,netdev=net0,addr=4 -bios /usr/share/ovmf/OVMF.fd

id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0,
delta 0
id 1, group 1, virt start 7fff1fe00000, virt end 7fff23dfe000,
generation 0, delta 7fff1fe00000
id 2, group 1, virt start 7fff1bc00000, virt end 7fff1fc00000,
generation 0, delta 7fff1bc00000

(qemu:1937): Spice-CRITICAL **: 20:17:21.623:
memslot.c:111:memslot_get_virt: slot_id 255 too big, addr=ff000000ff000000

(gdb) bt
#0  0x00007ffff0371e97 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff0373801 in __GI_abort () at abort.c:79
#2  0x00007ffff116fcc9 in spice_logv (log_domain=0x7ffff11da9f5 "Spice",
args=0x7fff36028cb0, format=0x7ffff11e1c5b "slot_id %d too big,
addr=%lx", function=0x7ffff11e1d90 <__FUNCTION__.15594>
"memslot_get_virt", strloc=0x7ffff11e1c78 "memslot.c:111",
log_level=G_LOG_LEVEL_CRITICAL) at log.c:183
#3  0x00007ffff116fcc9 in spice_log
(log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
strloc=strloc@entry=0x7ffff11e1c78 "memslot.c:111",
function=function@entry=0x7ffff11e1d90 <__FUNCTION__.15594>
"memslot_get_virt", format=format@entry=0x7ffff11e1c5b "slot_id %d too
big, addr=%lx") at log.c:196
#4  0x00007ffff11353b8 in memslot_get_virt
(info=info@entry=0x5555579bce10, addr=addr@entry=18374686483949813760,
add_size=add_size@entry=10, group_id=group_id@entry=1,
error=error@entry=0x7fff36028e08) at memslot.c:111
#5  0x00007ffff113e7d0 in red_get_image
(slots=slots@entry=0x5555579bce10, group_id=group_id@entry=1,
addr=<optimized out>, flags=flags@entry=0, is_mask=is_mask@entry=false)
at red-parse-qxl.c:512
#6  0x00007ffff113ea76 in red_get_copy_ptr
(slots=slots@entry=0x5555579bce10, group_id=group_id@entry=1,
red=red@entry=0x7fff1409f330, qxl=0x7fff1fe0107b, flags=flags@entry=0)
at red-parse-qxl.c:680
#7  0x00007ffff113f9a1 in red_get_native_drawable (flags=<optimized
out>, addr=<optimized out>, red=<optimized out>, group_id=<optimized
out>, slots=<optimized out>) at red-parse-qxl.c:1072
#8  0x00007ffff113f9a1 in red_get_drawable
(slots=slots@entry=0x5555579bce10, group_id=1,
red=red@entry=0x7fff1409f290, addr=<optimized out>, flags=0) at
red-parse-qxl.c:1206
#9  0x00007ffff11523cd in red_process_display (worker=0x5555579bcd80,
ring_is_empty=0x7fff36028f9c) at red-worker.c:224
#10 0x00007ffff1150d21 in flush_commands
(worker=worker@entry=0x5555579bcd80, red_channel=0x5555579b9210
[DisplayChannel], process=process@entry=0x7ffff1152220
<red_process_display>) at red-worker.c:315
#11 0x00007ffff1150e58 in flush_display_commands
(worker=worker@entry=0x5555579bcd80) at red-worker.c:352
#12 0x00007ffff11514bf in flush_all_qxl_commands (worker=0x5555579bcd80)
at red-worker.c:367
#13 0x00007ffff11514bf in destroy_primary_surface
(worker=0x5555579bcd80, surface_id=0) at red-worker.c:558
#14 0x00007ffff111f4f1 in dispatcher_handle_single_read
(dispatcher=0x555556a1d1c0 [Dispatcher]) at dispatcher.c:284
#15 0x00007ffff111f4f1 in dispatcher_handle_recv_read
(dispatcher=0x555556a1d1c0 [Dispatcher]) at dispatcher.c:304
#16 0x00007ffff1125d7b in watch_func (source=<optimized out>,
condition=<optimized out>, data=0x5555579bcf60) at event-loop.c:128
#17 0x00007ffff47911f5 in g_main_dispatch (context=0x5555579bce70) at
../../../../glib/gmain.c:3176
#18 0x00007ffff47911f5 in g_main_context_dispatch
(context=context@entry=0x5555579bce70) at ../../../../glib/gmain.c:3829
#19 0x00007ffff47915c0 in g_main_context_iterate
(context=0x5555579bce70, block=block@entry=1, dispatch=dispatch@entry=1,
self=<optimized out>) at ../../../../glib/gmain.c:3902
#20 0x00007ffff47918d2 in g_main_loop_run (loop=0x7fff14002530) at
../../../../glib/gmain.c:4098
#21 0x00007ffff1151b3a in red_worker_main (arg=0x5555579bcd80) at
red-worker.c:1372
#22 0x00007ffff072b6db in start_thread (arg=0x7fff3602c700) at
pthread_create.c:463
#23 0x00007ffff045488f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Às 18:28 de 01/02/2019, Dr. David Alan Gilbert escreveu:
> 
> Right yes; as you say with hda it's fine;  I've pointed Paolo at
> this one.
> 
> As for the original crash; I can't reproduce it here (On Fedora 29,
> head qemu):
> ./x86_64-softmmu/qemu-system-x86_64 -cpu host  -M pc,accel=kvm -smp 3 -m 8G -drive if=ide,file=/home/vmimages/kde-neon.qcow2 -display gtk,gl=on -device qemu-xhci,addr=3 -device qxl-vga,xres=1366,yres=768,addr=4 -bios /usr/share/OVMF/OVMF_CODE.fd
> 
> Dave
> 
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 

Re: [Qemu-devel] Crash when booting KDE Neon using qxl-vga

[Dr. David Alan Gilbert]

* Leonardo Soares Müller (leozinho29_eu@hotmail.com) wrote:
> I can confirm this, KDE Neon using the command line similar to yours
> crashes QEMU to me too. I will test with Mageia 7 later to see if it
> behaves differently.
> 
> But this is a completely different crash. This crash is happening
> earlier, what I reported first is a crash when the login screen should
> load, this is happening earlier on boot.
> 
> The command line I used this time:
> 
> qemu-system-x86_64 -M pc,accel=kvm -smp 3 -m 4G -drive
> if=virtio,file=neonbroken.qcow2 -vga qxl -bios /usr/share/ovmf/OVMF.fd

Yes, this was: https://bugs.launchpad.net/qemu/+bug/1813940

Dave

> The backtrace:
> 
> (gdb) bt
> #0  0x00007ffff0371e97 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x00007ffff0373801 in __GI_abort () at abort.c:79
> #2  0x000055555589eac9 in kvm_mem_ioeventfd_add
> (listener=0x555556a1fdc8, section=0x7fffc7ffba90, match_data=false,
> data=0, e=0x5555578c7fc8) at
> /home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:866
> #3  0x000055555588300a in address_space_add_del_ioeventfds
> (as=0x5555567e5a00 <address_space_memory>, fds_new=0x7fffbc000d30,
> fds_new_nb=1, fds_old=0x0, fds_old_nb=0) at
> /home/usuario/Documentos/qemu/memory.c:793
> #4  0x00005555558832f4 in address_space_update_ioeventfds
> (as=0x5555567e5a00 <address_space_memory>) at
> /home/usuario/Documentos/qemu/memory.c:843
> #5  0x000055555588415b in memory_region_transaction_commit () at
> /home/usuario/Documentos/qemu/memory.c:1094
> #6  0x00005555558871c8 in memory_region_add_eventfd (mr=0x5555578b6420,
> addr=0, size=0, match_data=false, data=0, e=0x5555578c7fc8) at
> /home/usuario/Documentos/qemu/memory.c:2303
> #7  0x0000555555c26cd0 in virtio_pci_ioeventfd_assign (d=0x5555578b5750,
> notifier=0x5555578c7fc8, n=0, assign=true) at hw/virtio/virtio-pci.c:243
> #8  0x0000555555c24dd5 in virtio_bus_set_host_notifier
> (bus=0x5555578bd848, n=0, assign=true) at hw/virtio/virtio-bus.c:283
> #9  0x00005555558ce648 in virtio_blk_data_plane_start
> (vdev=0x5555578bd8c0) at
> /home/usuario/Documentos/qemu/hw/block/dataplane/virtio-blk.c:200
> #10 0x0000555555c24af2 in virtio_bus_start_ioeventfd
> (bus=0x5555578bd848) at hw/virtio/virtio-bus.c:223
> #11 0x0000555555c26e57 in virtio_pci_start_ioeventfd
> (proxy=0x5555578b5750) at hw/virtio/virtio-pci.c:282
> #12 0x0000555555c29285 in virtio_pci_common_write
> (opaque=0x5555578b5750, addr=20, val=15, size=1) at
> hw/virtio/virtio-pci.c:1233
> #13 0x0000555555881ebd in memory_region_write_accessor
> (mr=0x5555578b6120, addr=20, value=0x7fffc7ffbf38, size=1, shift=0,
> mask=255, attrs=...) at /home/usuario/Documentos/qemu/memory.c:502
> #14 0x00005555558820cd in access_with_adjusted_size (addr=20,
> value=0x7fffc7ffbf38, size=1, access_size_min=1, access_size_max=4,
> access_fn=0x555555881dd4 <memory_region_write_accessor>,
> mr=0x5555578b6120, attrs=...) at /home/usuario/Documentos/qemu/memory.c:568
> #15 0x0000555555885100 in memory_region_dispatch_write
> (mr=0x5555578b6120, addr=20, data=15, size=1, attrs=...) at
> /home/usuario/Documentos/qemu/memory.c:1499
> #16 0x000055555581bca9 in flatview_write_continue (fv=0x7fffcc50f4f0,
> addr=34359738388, attrs=..., buf=0x7ffff7fee028 "\017", len=1, addr1=20,
> l=1, mr=0x5555578b6120) at /home/usuario/Documentos/qemu/exec.c:3234
> #17 0x000055555581bdf3 in flatview_write (fv=0x7fffcc50f4f0,
> addr=34359738388, attrs=..., buf=0x7ffff7fee028 "\017", len=1) at
> /home/usuario/Documentos/qemu/exec.c:3273
> #18 0x000055555581c0f9 in address_space_write (as=0x5555567e5a00
> <address_space_memory>, addr=34359738388, attrs=..., buf=0x7ffff7fee028
> "\017", len=1) at /home/usuario/Documentos/qemu/exec.c:3363
> #19 0x000055555581c14a in address_space_rw (as=0x5555567e5a00
> <address_space_memory>, addr=34359738388, attrs=..., buf=0x7ffff7fee028
> "\017", len=1, is_write=true) at /home/usuario/Documentos/qemu/exec.c:3374
> #20 0x00005555558a146f in kvm_cpu_exec (cpu=0x555556afe140) at
> /home/usuario/Documentos/qemu/accel/kvm/kvm-all.c:2031
> #21 0x0000555555865a3e in qemu_kvm_cpu_thread_fn (arg=0x555556afe140) at
> /home/usuario/Documentos/qemu/cpus.c:1281
> #22 0x0000555555e1ba02 in qemu_thread_start (args=0x555556b20440) at
> util/qemu-thread-posix.c:502
> #23 0x00007ffff072b6db in start_thread (arg=0x7fffc7fff700) at
> pthread_create.c:463
> #24 0x00007ffff045488f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> 
> 
> Às 11:36 de 01/02/2019, Dr. David Alan Gilbert escreveu:
> > 
> > Hmm, I'm also getting a crash, but I think it's very different from
> > yours:
> > 
> > ./x86_64-softmmu/qemu-system-x86_64 -M pc,accel=kvm -smp 3 -m 8G -cdrom /home/vmimages/neon-useredition-current.iso -drive if=virtio,file=/home/vmimages/kde-neon.qcow2 -vga qxl
> > 
> > kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device
> > Aborted (core dumped)
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK