qemu-system-x86_64 crashed with signal 5 in spice_log → red_get_clip_rects → red_get_clip_ptr → red_get_native_drawable → red_get_drawable → red_process_display → worker_source_dispatch

[Jean-Baptiste Lallement]

I was running a "disk defect" test from latest Bionic Ubuntu Desktop ISO.

ProblemType: Crash
DistroRelease: Ubuntu 18.04
Package: qemu-system-x86 1:2.11+dfsg-1ubuntu5
ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
Uname: Linux 4.15.0-13-generic x86_64
ApportVersion: 2.20.9-0ubuntu2
Architecture: amd64
Date: Thu Apr 5 10:12:50 2018
ExecutablePath: /usr/bin/qemu-system-x86_64
InstallationDate: Installed on 2014-07-15 (1359 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140520)
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
MachineType: Gigabyte Technology Co., Ltd. GA-890GPA-UD3H
ProcEnviron: PATH=(custom, no user)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=0889d734-ea91-4bdb-9d16-2a0a923ad3d1 ro quiet splash vt.handoff=1
Signal: 5
SourcePackage: qemu
StacktraceTop:
 () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
 () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
 () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
 () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
 () at /usr/lib/x86_64-linux-gnu/libspice-server.so.1
Title: qemu-system-x86_64 crashed with signal 5
UpgradeStatus: Upgraded to bionic on 2018-03-24 (11 days ago)
UserGroups: libvirt-qemu
dmi.bios.date: 07/23/2010
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: FD
dmi.board.name: GA-890GPA-UD3H
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrFD:bd07/23/2010:svnGigabyteTechnologyCo.,Ltd.:pnGA-890GPA-UD3H:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-890GPA-UD3H:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: GA-890GPA-UD3H
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

[Apport retracing service (apport)]

StacktraceTop:
 spice_logv (log_domain=0x7fdf72e4b195 "Spice", args=0x7fdf655fe5c0, format=0x7fdf72e4b09e "assertion `%s' failed", function=0x7fdf72e556a0 <__FUNCTION__.15482> "red_get_clip_rects", strloc=0x7fdf72e5512d "red-parse-qxl.c:352", log_level=G_LOG_LEVEL_ERROR) at log.c:178
 spice_log (log_level=log_level@entry=G_LOG_LEVEL_ERROR, strloc=strloc@entry=0x7fdf72e5512d "red-parse-qxl.c:352", function=function@entry=0x7fdf72e556a0 <__FUNCTION__.15482> "red_get_clip_rects", format=format@entry=0x7fdf72e4b09e "assertion `%s' failed") at log.c:196
 red_get_clip_rects (slots=slots@entry=0x55f8ffe1cf60, group_id=group_id@entry=1, addr=<optimized out>) at red-parse-qxl.c:352
 red_get_clip_ptr (qxl=0x7fded4814a2f, red=0x7fdf5c0d77d0, group_id=1, slots=0x55f8ffe1cf60) at red-parse-qxl.c:1020
 red_get_native_drawable (flags=0, addr=<optimized out>, red=0x7fdf5c0d7780, group_id=1, slots=0x55f8ffe1cf60) at red-parse-qxl.c:1049

[Christian Ehrhardt  (paelzer)]

Sig 5 is a Trap.

Qemu in the traces I see is mostly waiting and spawning a new vcpu.
The remaining (=the crashing) stack is in glib/spice handling.
Not seeing a direct fault in the call qemu makes.

Adding spice to get a spicy point of view on the crash as well - as I'm >=51% that the error is more there than directly in qemu.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.