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

Bug #1761406 reported by Jean-Baptiste Lallement
30
This bug affects 3 people
Affects Status Importance Assigned to Milestone
qemu (Ubuntu)
Confirmed
Medium
Unassigned
spice (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

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.

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
Revision history for this message
Apport retracing service (apport) wrote :

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

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceSource.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in qemu (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
information type: Private → Public
summary: - qemu-system-x86_64 crashed with signal 5
+ 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
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in qemu (Ubuntu):
status: New → Confirmed
Changed in spice (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.