Bug 479679

I cannot reproduce on KDE Neon Unstable.  Is your panel's configuration default, or have you changed anything?

(In reply to Doug from comment #1)
> I cannot reproduce on KDE Neon Unstable.  Is your panel's configuration
> default, or have you changed anything?

Just tried removing ~/.config/plasmashellrc, still happens
Last three lines are, in order:
layershellqt: Cannot attach popup of unknown type
xdg_wm_base@3: error 3: no xdg_popup parent surface has been specified
The Wayland connection experienced a fatal error: Protocol error

I'm having this issue on gentoo too but with kde's master branch; has this really been fixed or is this due to gentoo's packaging?

I'm having this exact issue on Gentoo.

Right clicking anywhere on the plasmashell panel or desktop results in this behavior. 

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo 2.14/5.92.0
(available in About System)
KDE Plasma Version: 5.92.0
KDE Frameworks Version: 5.248.0
Qt Version: 6.6.1

Relevant logs:
Jan 26 11:45:16 gentoo3 kwin_wayland_wrapper[1419]: error in client communication (pid 3515)
Jan 26 11:45:16 gentoo3 plasmashell[3515]: xdg_wm_base@3: error 3: no xdg_popup parent surface has been specified
Jan 26 11:45:16 gentoo3 systemd[1276]: plasma-plasmashell.service: Main process exited, code=exited, status=255/EXCEPTION
Jan 26 11:45:16 gentoo3 systemd[1276]: plasma-plasmashell.service: Failed with result 'exit-code'.
Jan 26 11:45:16 gentoo3 systemd[1276]: plasma-plasmashell.service: Consumed 2.103s CPU time.
Jan 26 11:45:16 gentoo3 systemd[1276]: plasma-plasmashell.service: Scheduled restart job, restart counter is at 2.
Jan 26 11:45:16 gentoo3 systemd[1276]: Starting KDE Plasma Workspace...
Jan 26 11:45:16 gentoo3 systemd[1276]: Started KDE Plasma Workspace.


Is there a patch that I can apply to test it, since this is marked as fixed?

Changing the status since it is actually not fixed

Cannot reproduce either with built-from-source Plasma on top of Fedora 39. I strongly suspect this is a packaging issue. Maybe the layershell protocol definition is out of date? Either way please follow up with Gentoo folks about it. Thanks!

No problem on my Gentoo Plasma 5.92 installation, so....?

(In reply to Nate Graham from comment #6)
> I strongly suspect this is a packaging issue. Maybe the layershell protocol
> definition is out of date?
We're shipping KF-5.248/Plasma-5.92 completely as-is, where do you suggest we start looking at?

Timur, what fixed it for you back on 2024-01-12 09:39:15 CET?

(In reply to Bernard from comment #3)
> I'm having this issue on gentoo too but with kde's master branch;
...just finished upgrading to 6.0 stable branch and still can't reproduce that bug in Gentoo.

(In reply to Bernard from comment #3)
> I'm having this issue on gentoo too but with kde's master branch

Same here. Plasmashell crashes on right click.

I'm on a clang(+libcxx) system. Might be interesting to hear what the others experiencing this issue are using.
Just to see if it might be a clang vs. gcc issue or if it happens with either toolchain.

(In reply to Jonas Rakebrandt from comment #10)
> I'm on a clang(+libcxx) system. Might be interesting to hear what the others
> experiencing this issue are using.
From downstream report I can see not clang but: -O3 -flto=thin

> From downstream report I can see not clang but: -O3 -flto=thin
I should have been more clear on this, I'm also on a clang(+libcxx) system.
Compiling frameworks, plasma and qt packages with gcc right now (w/o lto and -O3) to see if it makes a difference

Please try to be explicit about what makes your system interesting when using e.g. clang, -O3, and so on. Even if things should work in such a configuration, identifying what's _different_ is important.

Anyway, for runtime misbehaviour, try UBSAN and alternating compiler (so GCC if using Clang).

... also generally worth starting downstream for such things to not bother upstream until we've tried some basic stuff like that.

(In reply to Jonas Rakebrandt from comment #10)
> (In reply to Bernard from comment #3)
> > I'm having this issue on gentoo too but with kde's master branch
> 
> Same here. Plasmashell crashes on right click.
> 
> I'm on a clang(+libcxx) system. Might be interesting to hear what the others
> experiencing this issue are using.
> Just to see if it might be a clang vs. gcc issue or if it happens with
> either toolchain.

I was also using the clang compiler part of gentoo's glibc clang profile

Created attachment 165367 [details]
plasmashell clang ubsan logs

I was not able to recompile it with gcc due to many unresolved symbols. However I compiled frameworks/plasma/gear with clang and -march=native -pipe -O2 -g -fsanitize=undefined and the issue still persists.

Attached is the UBSAN log for the whole wayland plasma session until the crash.
There are some undefined behavior warnings but only during startup. After right clicking to trigger the crash no new UBSAN logs are written.

(In reply to Michael from comment #16)
> I was not able to recompile it with gcc due to many unresolved symbols.
Define "it"? Rebuilding Qt should go first in such cases, then Frameworks, then Plasma/Gear.(In reply to Bernard from comment #15)

> (In reply to Jonas Rakebrandt from comment #10)
> I was also using the clang compiler part of gentoo's glibc clang profile
Optimisations?

(In reply to Andreas Sturmlechner from comment #17)
> > I was also using the clang compiler part of gentoo's glibc clang profile
> Optimisations?

I used the "-march=native -O3 -pipe" flags, however as Michael said the issue persists with "-O2"

(In reply to Andreas Sturmlechner from comment #17)
> (In reply to Michael from comment #16)
> > I was not able to recompile it with gcc due to many unresolved symbols.
> Define "it"? Rebuilding Qt should go first in such cases, then Frameworks,
> then Plasma/Gear.(In reply to Bernard from comment #15)
> 
> > (In reply to Jonas Rakebrandt from comment #10)
> > I was also using the clang compiler part of gentoo's glibc clang profile
> Optimisations?

I also tried to compile QT, frameworks, plasma, gear (in this order) and managed to succeed, but due to ABI incompatibility(?) between libstdc++ and libc++ in many other system components I ended up with a broken desktop environment after restarting.

This issue still persists in RC2 with sane defaults flags (-O2 / no lto) on a systemwide clang/libc++ system.

I compiled qt / frameworks / plasma with "-O2 -ftrapping-math -fsemantic-interposition -ffp-contract=fast" to get a behavior as close as possible to gcc, but the same issue still persists.
Please let me know if you have further ideas to tackle this down.

Should this issue be reopened / moved? Both issues (upstream and downstream) are closed as resolved, but this still affects people with a clang/libcxx setup.

This just came up again in #plasma with clang/libc++, I think we have gathered enough cases to establish this is somehow caused or made visible by use of that particular toolchain, not downstream packaging.

The issue seems related to a mismatch in type_info across objects making the any_cast in layershell-qt fail

(In reply to David Redondo from comment #22)
> The issue seems related to a mismatch in type_info across objects making the
> any_cast in layershell-qt fail

libc++ uses pointer equivalence for typeinfo comparison by default.

(1.) struct xdg_popup is an incomplete type in layer-shell-qt. This triggers an LLVM bug: https://github.com/llvm/llvm-project/issues/36746. The result of that bug is that the typeinfo symbols (typeinfo + name) are local to the .so file and won't bind to other objects. Thus pointer equivalence checks fail.

If this gets fixed it'd probably work already. I don't see that being worked on though, so I suggest to build libc++ with -DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2, which mirrors libstdc++ behavior.

(More details for interested readers below)

There are also other ways this can fail, but don't happen here (yet):

2. layer-shell-qt is loaded with RTLD_LOCAL. That means typeinfo can't be shared between separately loaded plugins, just within (not runtime) linked libaries (i.e. what ldd shows). (ref. https://lists.llvm.org/pipermail/llvm-dev/2014-June/073469.html)
3. struct xdg_popup is also used by the executable itself. Unless the typeinfo is global by either building it with -rdynamic or linking it against a library which also exports the typeinfo, this can't be shared either. (ref. https://lists.llvm.org/pipermail/llvm-dev/2014-June/073487.html)

For those reasons, libstdc++ switched to using string comparison for typeinfo equality checks: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/libsupc%2B%2B/typeinfo;h=fcc3077d06091339175c7af5d3acd92fd5416acd;hb=HEAD#l51

1 is clearly a bug in clang. https://refspecs.linuxbase.org/cxxabi-1.83.html#rtti explains how typeinfo for pointers to incomplete types are supposed to work.

2 is technically intended behavior, just totally non obvious. 3 is similar, technically every executable which might call dlopen has to be built with -rdynamic.

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

(In reply to Fabian Vogt from comment #23)
> I suggest to build libc++ with
> -DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2, which mirrors libstdc++
> behavior.

Can confirm this works. Note that you need to rebuild everything against the new libc++ (or at least relevant packages, which those are I don't know exactly, plasma-workspace and layer-shell-qt alone did not work for me so I just did every dependency of plasma-workspace).