plasmashell crashes on startup [solved]

jesnow · l33t Joined: 26 Apr 2006 Posts: 856

I am experiencing identical symptoms to this:

https://forums.gentoo.org/viewtopic-t-1121630-start-0.html

Plasmashell crashes on start, then restarts itself and crashes again.

BUT I am not using the calendar app, and have no relevant settings to delete.

Any help in troubleshooting would be appreciated, as the computer is somewhat useless without plasmashell, which turns out to be delicate.

mistermock · n00b Joined: 12 Jan 2005 Posts: 12

Hi,

here plasmashell crashed too.

The problem (I think): Wrong file permission settings for the ~/.cache/ksycoca5_***** file.
After changing permissions to 755 or 777 plasmashell works again.

Hope this helps.
mistermock

jesnow · l33t Joined: 26 Apr 2006 Posts: 856

That doesn't make any sense. Anything in ~.cache can be deleted and is recreated. And plasmashell process is owned wholly by the user, nobody else would try to access its temp files. But I tried it (no effect) and I deleted it (no effect). So that's not it.

Apparently plasmashell crashed for mysterious reasons having to do with plasmoids, widgets and other useless things.

Cheers,
Jon.

jesnow · l33t Joined: 26 Apr 2006 Posts: 856

Here's my attempt to restart Plasmashell. Regardelss of whether I have a misconfig, code this mature should never crash. But it doess, for all kinds of reasons, if you look out in the googles.

Filing bug.

Cheers,
Jon.

mistermock · n00b Joined: 12 Jan 2005 Posts: 12

I thought the same.
The problem started after deleting files in .cache.
ksycoca5_**** was recreated but the permissions were set incorrectly so the file could not be opened.
After I changed the permissions, plasmashell worked again. :-)

That's what I did.

jesnow · l33t Joined: 26 Apr 2006 Posts: 856

I tried it, but that didn't work:

asturm · Developer Joined: 05 Apr 2007 Posts: 8936

Did you try the obvious already, i.e. with a clean testuser?

jesnow · l33t Joined: 26 Apr 2006 Posts: 856

Thanks! No, but I just did, same issue. Also the same error message that always happens right before it crashes.

jesnow · l33t Joined: 26 Apr 2006 Posts: 856

I filed a bug with KDE, the best they had to offer was :

jesnow · l33t Joined: 26 Apr 2006 Posts: 856

Here is the Backtrace from Dr. Konqi:

This is a real crash.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

An unidentified (no debug symbols) function in Qt5Core tried to convert a double precision floating point value to a string, which triggered an assertion failure in the conversion library. Personally, I think it's poor form to have a publicly exposed library function that dies with an assertion failure when a caller from outside the library passes it unacceptable data. Printing the value of v, or rebuilding more of Qt with debug symbols, might prove informative.

jesnow · l33t Joined: 26 Apr 2006 Posts: 856

Hu to the rescue! Thank you, that's my thought exactly. I didn't have drkonqi installed, which requires gdb, which didn't like my stupid cflags (as you know I have continuing issues with that, but it's a different rabbit hole). But I figured all that out and got the backtrace you see above. I compiled plasma-workspace with debugging symbols (following the gentoo debugging guide) and ran it, set a few breakpoints, but learned nothing new. I still don't know where it's calling the function that eventually causes glibc to fail on an assert. As you say, it seems like plasma-workspace should not ever make a call that causes qt to make a bad call, and qt should never pass along a call to glibc that causes it to die with an assert failure. So that's two levels of bugs. Glibc for its part is behaving correctly and identifying what went wrong.

My next step I guess is to recompile glibc and qtcore with debugging symbols. You know, it really helps writing this out: In fact that's wrong, the next step is to compile qtcore with more vanilla cflags and see what happens. Glibc is already just vanilla -O2, but qtcore is -Ofast.

Cheers,
Jon.

jesnow · l33t Joined: 26 Apr 2006 Posts: 856

Boom. Fixed it myself with an assist from Hu.

For the record, for anybody who reads this thread, if you compile qtcore with -Ofast it throws mysterious errors seemingly having to do with the -ffast-math optimization. -O3 may work better, but -O2 is safer.

I will now revert all the kde packages to the -Ofast optimization, and file a bug with qt -- their libraries should be both -Ofast and idiot-proof.

Cheers,

Jon.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

asturm · Developer Joined: 05 Apr 2007 Posts: 8936

Roaming through KDE Qt5PatchCollection issues brought up some bigger upstream meta task that may or may not be related to this:

https://bugreports.qt.io/browse/QTBUG-99545

However, pure speculation until more debug symbols are avaialble in the output.

Bugs to Qt5 are no longer processed at Qt(Company) upstream anyway, unless from paying customers; the crash would need to be reproduced in Qt6 with a fix then potentially deemed worthy as "Pick-to: 5.15" by upstream developers from which it could end up cherry-picked (by someone like me, e.g.) earlier than 1 year after the upstream Qt-5.15 LTS release containing the fix to KDE's Qt5PatchCollection. But then by the time you can try to reproduce this within a future Plasma 6 you may not be interested in 5 anymore.