Created attachment 120608 [details] Valgrind output with wayland built from git master on KDE Neon unstable SUMMARY There is a use-after free problem in plasma-integration/libkf5waylandclient/libwaylandclient. STEPS TO REPRODUCE 1. log into a Plasma Wayland session 2. start any KDE (or Qt widget) application with environment variables 'MALLOC_CHECK_=2 MALLOC_PERTURB' set. OBSERVED RESULT The application crashes, e.g. like this: $ MALLOC_CHECK_=2 MALLOC_PERTURB_=153 kate kate: ../src/wayland-client.c:226: wl_proxy_unref: Assertion `proxy->refcount > 0' failed. Aborted (core dumped) EXPECTED RESULT The application should run just fine. SOFTWARE/OS VERSIONS VM with: Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.16.80 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.0 Kernel Version: 4.18.0-21-generic OS Type: 64-bit Processors: 4 × Intel Xeon E3-12xx v2 (Ivy Bridge) Memory: 7,7 GiB of RAM ADDITIONAL INFORMATION * Package versions on KDE Neon (originally observed in Debian testing with older versions): * plasma-integration: 5.15.5+p18.04+git20190604.0336-0 * libkf5waylandclient5: 4:5.58.0+p18.04+git20190602.0143-0 * The real world use case is LibreOffice with its relatively new qt5/kde5 integration. The LibreOffice shell wrapper sets the above two environment variables, so LibreOffice currently doesn't start in a Plasma Wayland session with kde5 integration in use. * The same happens when using upstream wayland libs built from its current master branch (as of commit 78c8681e28739da1fea667ae59118cfc0968497). * Valgrind output for that scenario attached.
[18:21] <d_ed> you don't want to create a second XdgShellSurface, Qt has one internally [18:25] <d_ed> it's a protocol violation so a correct compositor should kick out the client [18:26] <d_ed> unfortunately Qt's XdgShellTopLevel object is not exposed anywhere That needs a patch in Qt at which point we may as well support setAppId explicitly there. Will leave this open to remind us to fix.
I can't reproduce this anymore with Plasma 5.19.5 on a current Debian testing (with libwayland-client0 1.18.0-2~exp1.1, plasma-integration 5.19.5-3). -> Closing as WORKSFORME (In reply to David Edmundson from comment #1) > [18:21] <d_ed> you don't want to create a second XdgShellSurface, Qt has one > internally > [18:25] <d_ed> it's a protocol violation so a correct compositor should kick > out the client > [18:26] <d_ed> unfortunately Qt's XdgShellTopLevel object is not exposed > anywhere > > > That needs a patch in Qt at which point we may as well support setAppId > explicitly there. > > Will leave this open to remind us to fix. @David: I don't immediately see how this is related to the issue originally reported here - to me, this comment sounds more related to https://bugreports.qt.io/browse/QTBUG-77182 (Qt: "Export Wayland xdg_toplevel app ID to allow changing the icon of a Window") and https://bugs.documentfoundation.org/show_bug.cgi?id=125934 (LibreOffice: "No application icon on Wayland with the qt5 / kf5 backend") , respectively...