KDE plasma-welcome and plasmashell crash after SDDM log in

Shadow_Fury

a continuation of this thread.

i figured it was time for a new thread with a more descriptive title. (if i should have done something else than starting a new thread, please tell me)

i'll collate some related information here, but please see the other thread f0r additional details.

first, Xorg itself seems to work fine. much testing was done, and it seems to be working fine.

next, after logging in with sddm, the plasma loading screen appears, but once it disappears, i'm left with only a black screen and a mouse pointer.

the user is already in the video, input, and sddm groups.

whilst examining logs, it seems that all of the plasma apps that attempt to launch (plasma-welcome, plasmashell, drkonqi) crash almost immediately.

here are some straces from a non-root user:
plasmashell
plasma-welcome

and the error output of plasmashell:

CooSee · Veteran Joined: 20 Nov 2004 Posts: 1540 Location: Earth

TL;DR the other thread.

pingtoo · Posted: Thu Mar 16, 2023 10:27 pm Post subject:

Shadow_Fury,

I don't use KDE and certainly not Plasma. So I am guessing here.

I look both strace file for plasma-welcome and plasmashell. I found for plasma-welcome it is looking for /home/shadow/.config/plasma-welcomerc which seems not exist.

whereas for plasmashell the /home/shadow/.config/plasmashellrc does exist however it also looking for /home/shadow/.config/plasmarc which does not exist.

I don't know if those program missing "rc" file will cause it crash or not. it is possible because the program search path also looking system directory like /usr/share or /usr/lib or /etx/xdg. none of those place program can find a "rc" file it looking for. So this is first guess.

The second guess is that plasmashell seems to failed at the something about fontconfig. But I am not sure. I cannot find reference on my machine because my machine have very old gentoo setup that seems have different .local directory structure.

It is very possible missing "rc" file is not impotent because the program have correct default values. however it is also possible those program expecting there is a global configure which seems also missing.

Do you have /tmp/runtime-shadow directory? is there something there may be able to help debug?

Shadow_Fury · Posted: Fri Mar 17, 2023 10:40 pm Post subject:

Hu · Administrator Joined: 06 Mar 2007 Posts: 23336

Have you tried running the program under gdb and examining the program context at the time of the crash? DrKonqi is supposed to do something for post-crash analysis, but it appears to be too broken in this case, so you will need to start the offending program under gdb and catch it as it faults.

CooSee · Veteran Joined: 20 Nov 2004 Posts: 1540 Location: Earth

just a wild guess, is your user in plugdev group ?

_________________
" Die Realität ist eine Illusion, die durch Mangel an ehrlicher Kommunikation entsteht "
---
" Der Mensch ist von Natur aus neugierig, was am Ende übrig bleibt ist die Gier "

GDH-gentoo

This won't help a lot, but:

Hu · Administrator Joined: 06 Mar 2007 Posts: 23336

Nice catch. I saw the OP report it as a crash and took it at face value that this was a crash, and not an assertion failure, so I missed seeing that message in the output. I concur with your analysis, and will note that _LIBCPP_ASSERT is a no-op if _LIBCPP_DEBUG_LEVEL == 0, and has this assert-like behavior if _LIBCPP_DEBUG_LEVEL != 0. Therefore, for people who build with _LIBCPP_DEBUG_LEVEL == 0, this assertion is omitted and a reference to the disengaged value is returned. That may or may not cause problems later, but it won't lead to the nice clean abort reported here. On my system, clang defaults to _LIBCPP_DEBUG_LEVEL == 0. Evidently, OP has built this package with libc++ debugging enabled, possibly because the package always does that or possibly as a result of some local profile adjustments.

Shadow_Fury · Posted: Sun Mar 19, 2023 1:55 am Post subject:

GDH-gentoo · Posted: Sun Mar 19, 2023 8:48 pm Post subject:

Shadow_Fury · Posted: Sun Mar 19, 2023 9:26 pm Post subject:

GDH-gentoo · Posted: Sun Mar 19, 2023 9:54 pm Post subject:

Shadow_Fury · Posted: Sun Mar 19, 2023 10:01 pm Post subject:

then why is the assertion fail still triggering, this is the same libcxx as before. nothing at all has changed

GDH-gentoo · Posted: Sun Mar 19, 2023 10:27 pm Post subject:

Shadow_Fury · Posted: Mon Mar 20, 2023 2:18 am Post subject:

rebuilt the x11/qt/kde stack with this:

GDH-gentoo · Posted: Mon Mar 20, 2023 4:34 pm Post subject:

Since missing a package that uses std::optional<> is too easy (it's a standard library component after all), it's probably time to use GDB, as Hu suggested. I'd start by rebuilding sys-libs/libcxx, kde-plasma/plasma-workspace and kde-plasma/plasma-welcome with debugging information, and then seeing what GDB shows.
_________________