xdg-desktop-portal
xdg-desktop-portal copied to clipboard
Segfault when launching screen sharing
Operating System
KDE Neon 6.0 (Ubuntu 22.04)
XDG Desktop Portal version
1.18
Desktop Environment
KDE Plasma 6.1.3
Expected Behavior
When starting a screen sharing session, a window appears allowing to choose what to share (single screen, single app...). Clicking on any option, the screen sharing should start right away.
Current Behavior
Immediately upon clicking on any options, I have a segfault that terminates the process immediately.
Steps to Reproduce
- Go to https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing/
- Press Share your screen Alternatively, trigger a screen sharing from any application.
- Choose any option other than a specific tab inside Chrome. Core dumped.
Anything else we should know?
This seems to be related to libpipewire-module-protocol-native.so but when rolling back to an earlier release of xdg-desktop-portal (like 1.14.4 which is available in my distro) everything works fine.
The logs, attached: xdg-desktop-portal.log
The log file is a good start, but sadly it's missing debug symbols. Please install the debug packages of xdg-desktop-portal on your distro, and provide us with a backtrace. Here's a guide on how to grab that: https://handbook.gnome.org/issues/stack-traces.html
I managed to grab this in gdb but I'm not sure that's what you need:
...
[New Thread 0x7fffe6ffd640 (LWP 13922)]
Thread 4 "pool-/usr/libex" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5bfd640 (LWP 13812)]
0x00007ffff4b75c15 in ?? () from /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so
(gdb) bt
#0 0x00007ffff4b75c15 in () at /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so
#1 0x00007ffff4b7c92b in () at /usr/lib/x86_64-linux-gnu/pipewire-0.3/libpipewire-module-protocol-native.so
#2 0x00007ffff7b91d42 in pw_proxy_destroy () at /lib/x86_64-linux-gnu/libpipewire-0.3.so.0
#3 0x00005555555c843d in pipewire_remote_destroy (remote=0x7fffec00f8e0) at ../src/pipewire.c:225
#4 0x00005555555cde8a in handle_open_pipewire_remote (object=<optimized out>, invocation=0x7fffe801a910, in_fd_list=<optimized out>, arg_session_handle=<optimized out>, arg_options=<optimized out>) at ../src/screen-cast.c:1005
#5 0x00007ffff762be2e in () at /lib/x86_64-linux-gnu/libffi.so.8
#6 0x00007ffff7628493 in () at /lib/x86_64-linux-gnu/libffi.so.8
#7 0x00007ffff7c3e16d in g_cclosure_marshal_generic () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x00007ffff7c37d2f in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x00007ffff7c53624 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x0000555555597d54 in _xdp_dbus_screen_cast_skeleton_handle_method_call
(connection=<optimized out>, sender=<optimized out>, object_path=<optimized out>, interface_name=0x55555564fd70 "org.freedesktop.portal.ScreenCast", method_name=0x7fffe801c8f0 "OpenPipeWireRemote", parameters=<optimized out>, invocation=0x7fffe801a910, user_data=0x555555707ae0)
at src/xdp-dbus.c:49660
#11 0x00007ffff7da815e in () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#12 0x00007ffff7d35194 in () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#13 0x00007ffff7ee4714 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff7ee1ab1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007ffff7894ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#16 0x00007ffff7926850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Looks https://github.com/flatpak/xdg-desktop-portal/commit/24d29bf1cc0e68521f082db4673999478a5923c9 is the reason for your crash.
Can you also install debug symbols for PipeWire and provide more detailed backtrace?
I'm not used to this kind of low level debugging so I might have missed something: I've installed the folowing debug symbols:
libkpipewire6-dbgsym
libkpipewirerecord6-dbgsym
qml6-module-org-kde-pipewire-dbgsym
xdg-desktop-portal-dbgsym
xdg-desktop-portal-kde-dbgsym
But when I run gdb /usr/libexec/xdg-desktop-portal I still get the same output as before, nothing more.
Also, I do this when running gdb:
This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.neon.kde.org/
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
Not sure how the the dbgsym packages and the debuginfod correlates...
I'm not used to this kind of low level debugging so I might have missed something: I've installed the folowing debug symbols:
libkpipewire6-dbgsym libkpipewirerecord6-dbgsym qml6-module-org-kde-pipewire-dbgsym xdg-desktop-portal-dbgsym xdg-desktop-portal-kde-dbgsym
Those are debug symbols for KPipeWire and not PipeWire. KPipeWire is a KDE library wrapping some PipeWire functionality, but it's not involved here. I believe the package will be simply called pipewire so you want to install pipewire-dbgsym I guess.
So I installed the metapackage neon-repositories-ubuntu-ddebs which seems to add the dbgsym packages repository on KDE Neon but unfortunately, I get this message when I try to install pipewire-bin-dbgsym or libpipewire-0.3-0-dbgsym:
Package [xxx] has no available version, but exists in the database.
This typically means that the package was mentioned in a dependency and never uploaded, has been obsoleted or is not available with the contents of sources.list
I'm leaving on vacation tomorrow so we will resume this conversation in a week or so.
I ran into this bug also and I'm also on KDE Neon with KDE 6.1.3, downgrading xdg-desktop-portal works also for me
sudo apt install xdg-desktop-portal=1.14.3-0ubuntu2
https://discuss.kde.org/t/kde-neon-plasma-6-1-screen-sharing-error-in-wayland/17334/11
Update for KDE 6.2
There have been reports that this no longer works on KDE 6.2 so be mindful of that.
I'm now having (probably) same crash with Firefox, where it crashes on pw_proxy_destroy() same as here.
Output:
firefox: ../src/pipewire/proxy.c:265: pw_proxy_unref: Assertion `proxy->refcount > 0' failed.)
or
firefox: ../src/pipewire/proxy.c:210: pw_proxy_destroy: Assertion `!proxy->destroyed' failed.
Should we be destroying it ourself? From the docs:
Note:
This is normally called by [Core](https://docs.pipewire.org/group__pw__core.html) when the server decides to destroy the server side object
The downgrade to older xdg-desktop-portal makes the crash go away, because we didn't destroy the proxy object before.
I'm not reproducing it. What exact versions are used, including Chrome and Firefox (flatpak or not)?
I'm not reproducing it. What exact versions are used, including Chrome and Firefox (flatpak or not)?
KDE Neon 6.0 (Ubuntu 22.04)
I'd suspect this to be an old bug in PW, assuming that a rather old version of it is used. Checking if the issue is reproducible on Ubuntu 24.04 based systems would be very helpful.
According to the site ubuntu packages, Ubuntu 22.04 is using pipewire 0.3.48. Me using Fedora 40 and pipewire is 1.0.7...
Can confirm my KDE Neon 6.1.4 is currently on Pipewire 0.3.48 where this bug is present. KDE Neon is usually 0-2 versions behind on their Ubuntu base. This could be the culprit.
Stack trace with pipewire symbols, from the Debian package rebuilt with DEB_BUILD_OPTIONS=nostrip (there are no dbgsym packages):
#0 impl_ext_begin_proxy (proxy=<optimized out>, opcode=7 '\a', msg=0x0) at ../src/modules/module-protocol-native.c:1267
#1 0x00007ffff6bce92b in core_method_marshal_destroy (object=0x7fffd0026220, p=<optimized out>)
at ../src/modules/module-protocol-native/protocol-native.c:303
#2 0x00007ffff7b7fd42 in pw_proxy_destroy (proxy=0x7fffd00395b0) at ../src/pipewire/proxy.c:243
#3 0x00005555555c843d in pipewire_remote_destroy (remote=0x7fffd0009750) at ../src/pipewire.c:225
#4 0x00005555555cde8a in handle_open_pipewire_remote
(object=<optimized out>, invocation=0x7fffe4005520, in_fd_list=<optimized out>, arg_session_handle=<optimized out>, arg_options=<optimized out>)
at ../src/screen-cast.c:1005
Given that this seems to be an old pipewire issue, should we close this?
I guess so. I hope pipewire will be updated in the next Neon version. In the meantime going back to v1.14.4 fixes the issue.
Informed Neon devs of the workaround in case they want to patch it in the current version.