Created attachment 1527931 [details]
File: backtrace

Created attachment 1527932 [details]
File: cgroup

Created attachment 1527933 [details]
File: core_backtrace

Created attachment 1527934 [details]
File: cpuinfo

Created attachment 1527935 [details]
File: dso_list

Created attachment 1527936 [details]
File: environ

Created attachment 1527937 [details]
File: exploitable

Created attachment 1527938 [details]
File: limits

Created attachment 1527939 [details]
File: maps

Created attachment 1527940 [details]
File: mountinfo

Created attachment 1527941 [details]
File: open_fds

Created attachment 1527942 [details]
File: proc_pid_status

*** Bug 1677944 has been marked as a duplicate of this bug. ***

I am raising the priority as its really difficult to use VM's. I upgraded from Fedora 29 to Fedora 30 and tried to use existing VM. The VM images starts but gets killed soon. This is causing problem on Fedora 30 not to use VM's.

Does switching the display type to VNC fix things? Since the backtrace is from gstreamer this is likely triggered through spice

Since this is really deep in a gstreamer call stack, I'm reassigning to gstreamer1

Yeah, switching to VNC "fixes" things. Bug happens with virtio+spice and qxl+spice, does not happen with qxl+vnc.

Note the bug seems to happen when a graphical environment starts. spice is OK if the vm stays at a console.

Thanks Adam, qxl+vnc worked for me as well but not others.

This could be fixed by https://github.com/GStreamer/gst-plugins-good/commit/f5bb377a787f6516f25c964939afac682cce62ac#diff-5de4624da8356ade0b58ebf8c57cba0d

Well, I would test that, but it's blocked by the package failing to build for what seems to be an unrelated reason:

BUILDSTDERR: gstvpxdec.c: In function 'gst_vpx_dec_post_processing_flags_get_type':
BUILDSTDERR: gstvpxdec.c:65:15: error: 'VP8_DEBUG_TXT_FRAME_INFO' undeclared (first use in this function)
BUILDSTDERR:    65 |     {C_FLAGS (VP8_DEBUG_TXT_FRAME_INFO),

https://koji.fedoraproject.org/koji/taskinfo?taskID=32929807

I'd guess that's to do with the overlinking protection that was recently added to Rawhide/F30...

I guess https://github.com/GStreamer/gst-plugins-good/commit/b6e6f1ae73375ef66a5748069843aaed1a83e6a6 may be the fix for it in fact...

OK, yeah, with that patch too the package builds. https://koji.fedoraproject.org/koji/taskinfo?taskID=32930099 is the scratch build if anyone else wants to test.

The behaviour is *different* now but I wouldn't say it's fixed exactly. virt-manager doesn't crash any more, but as soon as the guest hits a graphical environment, it gets *extremely* slow. I thought it had hung, but no, it does *eventually* start displaying the desktop in the VM, but it takes a long time and I keep getting ""Virtual Machine Manager" is not responding" prompts because it's so slow...

(In reply to Adam Williamson from comment #21)
> OK, yeah, with that patch too the package builds.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=32930099 is the scratch
> build if anyone else wants to test.
> 
> The behaviour is *different* now but I wouldn't say it's fixed exactly.
> virt-manager doesn't crash any more, but as soon as the guest hits a
> graphical environment, it gets *extremely* slow. I thought it had hung, but
> no, it does *eventually* start displaying the desktop in the VM, but it
> takes a long time and I keep getting ""Virtual Machine Manager" is not
> responding" prompts because it's so slow...

Is there anything logged either from virt-manager in the terminal you are running it from (with --no-fork), or in the libvirtd log for that VM?
Do you get the same slowness with virt-manager?

So, if I run from a console with --no-fork , around the time it starts getting really slow, I get this message:

[Thu, 21 Feb 2019 09:12:19 virt-manager 6103] DEBUG (connection:760) domain agent lifecycle event: domain=desktop_test_1 state=VIR_CONNECT_DOMAIN_EVENT_AGENT_LIFECYCLE_STATE_CONNECTED reason=2

then a minute and a half later, this happens:

[Thu, 21 Feb 2019 09:13:57 virt-manager 6103] DEBUG (connection:1444) Error polling connection qemu:///system
NoneType: None
[Thu, 21 Feb 2019 09:13:57 virt-manager 6103] DEBUG (connection:1449) Not showing user error since libvirtd appears to have stopped.
[Thu, 21 Feb 2019 09:13:57 virt-manager 6103] DEBUG (connection:940) conn.close() uri=qemu:///system
[Thu, 21 Feb 2019 09:13:57 virt-manager 6103] DEBUG (connection:955) Failed to deregister events in conn cleanup
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 946, in close
    self._backend.domainEventDeregisterAny(eid)
  File "/usr/lib64/python3.7/site-packages/libvirt.py", line 5091, in domainEventDeregisterAny
    if ret == -1: raise libvirtError ('virConnectDomainEventDeregisterAny() failed', conn=self)
libvirt.libvirtError: internal error: client socket is closed

and virt-manager drops the connection to libvirtd.

libvirtd logs don't show anything relevant (only a bunch of 'Failed to open file' errors for other VMs which are due to a network filesystem bug that has nothing to do with this).

Similar problem has been detected:

Open CentOS 7 VM with graphical target running.

reporter:       libreport-2.10.0
backtrace_rating: 4
cmdline:        /usr/bin/python3 /usr/share/virt-manager/virt-manager
crash_function: gst_caps_set_simple_valist
executable:     /usr/bin/python3.7
journald_cursor: s=9fa69736500b4406a5fad8856af3090c;i=377a6;b=23ac30b071944f2d89acdc4a4b063227;m=1f0361d9f0;t=5827965d88625;x=657dc5cc5e4000c4
kernel:         5.0.0-0.rc6.git1.1.fc30.x86_64
package:        virt-manager-2.1.0-1.fc30
reason:         python3.7 killed by SIGSEGV
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

The same thing happens when trying to run a vm in Boxes (F30). Entire app just goes down.

Proposed as a Blocker for 30-beta by Fedora user frantisekz using the blocker tracking app because:

 The release must be able host virtual guest instances of the same release.

I don't think the workaround of using VNC is good enough. Also, because Boxes are crashing too, this probably fits as breaking Beta blocking TC: "QA:Testcase_workstation_core_applications".

*** Bug 1684123 has been marked as a duplicate of this bug. ***

Discussed during the 2019-03-04 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

"The release must be able host virtual guest instances of the same release."

We note that using VNC can be considered a 'workaround', but still think the bug is a blocker, and note that it is not straightforward to do this in Boxes and it is not equal in quality to the default configuration.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-03-04/f30-blocker-review.2019-03-04-17.03.txt

Moving to gstreamer1-plugins-good as this is where the pulseaudio plugin lives. See comment #18 and the next ones for a bunch of fixes which needs backporting.

Similar problem has been detected:

Started a virtual machine (f30) on a f30 host.
Virt-viewer crashes when reaching graphical target.
I saw lightdm login manager just before the crash happens.
Same happens if i am using virt-viewer to fire up the VM.
It happens with all VMs which i use.
All VMs are starting well under f28 or f29 host.
I am using a dualboot system with several fedora versions.

reporter:       libreport-2.10.0
backtrace_rating: 4
cmdline:        /usr/bin/python3 /usr/share/virt-manager/virt-manager
crash_function: gst_caps_set_simple_valist
executable:     /usr/bin/python3.7
journald_cursor: s=1d4f5cc7a71e4384a44220d63b996328;i=83cfe;b=e0e98ecacc1345f7a20ba6220dac867c;m=b0d68e6f;t=583bc3c972923;x=e056c3991a370a32
kernel:         5.0.0-300.fc30.x86_64
package:        virt-manager-2.1.0-1.fc30
reason:         python3.7 killed by SIGSEGV
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Opp, (In reply to Wolfgang Ulbrich from comment #30)
> Similar problem has been detected:
> 
> Started a virtual machine (f30) on a f30 host.
> Virt-viewer crashes when reaching graphical target.
opps, typo, crash was with virt-manager.

*** Bug 1687148 has been marked as a duplicate of this bug. ***

After updating to gstreamer1-1.15.2-2.fc30.x86_64 the problem seems to be fixed.

Yeah, gstreamer1-1.15.2-2.fc30.x86_64 ( https://bodhi.fedoraproject.org/updates/FEDORA-2019-a5b184ce96 ) fixes the issue. I don't see any slowdowns that Adam mentioned in the comment #21 . The only regression is broken 3D acceleration (opengl), I'll create separate bug for that.

yeah, the build in the update seems to work fine for me also. Thanks a lot.

The update was pushed stable, so closing this.