If something crashed, we need a backtrace of it so we can figure out what's going on. A screenshot of the thing reporting the crash isn't useful; we need the actual backtrace. which you can get by clicking the "Developer information" button. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports.

Can you please attach the backtrace? Thanks!

I tried but I'm completely lost. Crash aside, this blank screen and the rearrangement are important too and they happen without a crash. It just crash sometimes, but in first place I'm more interested in why there's a matter for the DE if the monitor is of or on.

This is for 5-th time since yesterday. When I click on developer information, it waits for something for a while (Waiting for data) and thab it closes so I can't see the packages:

https://i.imgur.com/dtI23vt.png

So, what I can do? Post a new bug with rearrangement and a blank screen problems only?

Ah, and something more - in the window debuginfold says "answered N". I didn't answered anything at all. How I can change this behaviour?

I installed the debugging symbols but the crash reporter continue to close after a while. How I'm supposed to gather the required information?

Luckily enough it crashes quite often. This time I decided to directly report a bug from the Report Tool. Again it dissapeared after a while:
https://i.imgur.com/7oGmrmW.png

If I do nothing, it again dissapear itself after some time. As you can see there's no panel. After the Crash Reporter closes itself, the panel appear and it open all previously opened apps but rearrange them. What I should do?

Click the "Show backtrace content" button in that screenshot.

I tried. It waits a while and the reporter closes. Once it managed to endure enough to show it, I very fastly copied it and when the reporter closed just a second after that, the clipboard was empty...

The screenshot is when it yet gathers the information. 99.9% of the times I can't press this button for it isn't ready yet so I can't do anything but watch how it'll close in a few seconds.

Finally managed to copy the info. Thanks god it crashes almost every time I turn on my monitor:
https://pastebin.com/ruQCJY0N

It finaly managed to create a coredump. It's from today:
https://pastebin.com/mpQmUVb2

Do you need to upload the coredump so you can analyse it?

And the result of coredumpctl info plasmashell:
https://pastebin.com/GH6GcB6w

I have 3-4 dumps everyday, do you need them?

Thank you, that's helpful. Relevant part of the backtrace:


#9  0x00007fa0c30d2002 in std::__glibcxx_assert_fail(char const*, int, char const*, char const*) (file=file@entry=0x555c682988b8 "/usr/include/c++/12.1.0/bits/stl_algo.h", line=line@entry=3623, function=function@entry=0x555c68298860 "constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&) [with _Tp = int]", condition=condition@entry=0x555c68298653 "!(__hi < __lo)") at /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:60
#10 0x0000555c68252b10 in std::clamp<int>(int const&, int const&, int const&) (__val=<optimized out>, __lo=<optimized out>, __hi=<optimized out>) at /usr/include/c++/12.1.0/bits/stl_algo.h:3621
        minSize = 1280
        targetSize = {wd = -1, ht = -1}
        targetMinSize = {wd = 1280, ht = 30}
        targetMaxSize = {wd = 0, ht = 30}
#11 std::clamp<int>(int const&, int const&, int const&) (__hi=<synthetic pointer>: <optimized out>, __lo=<synthetic pointer>: <optimized out>, __val=@0x555c6982b0a4: 602) at /usr/include/c++/12.1.0/bits/stl_algo.h:3621
        minSize = 1280
        targetSize = {wd = -1, ht = -1}
        targetMinSize = {wd = 1280, ht = 30}
        targetMaxSize = {wd = 0, ht = 30}
#12 PanelView::resizePanel() (this=this@entry=0x555c6982b060) at /usr/src/debug/plasma-workspace-5.25.2/shell/panelview.cpp:629
        minSize = 1280
        targetSize = {wd = -1, ht = -1}
        targetMinSize = {wd = 1280, ht = 30}
        targetMaxSize = {wd = 0, ht = 30}
#13 0x0000555c68253d35 in PanelView::setThickness(int) (this=this@entry=0x555c6982b060, value=<optimized out>) at /usr/src/debug/plasma-workspace-5.25.2/shell/panelview.cpp:269
#14 0x0000555c682583c7 in PanelView::restore() (this=0x555c6982b060) at /usr/src/debug/plasma-workspace-5.25.2/shell/panelview.cpp:670
        panelConfig = {<KConfigBase> = {_vptr.KConfigBase = 0x7fa0c4ffc110 <vtable for KConfigGroup+16>}, d = {d = 0x555c6a9055b0}}
        screenSize = {wd = 0, ht = 1616761969}
        side = <optimized out>
        maxSize = <optimized out>



It seems like it's trying to resize it to an invalid size and then crashes. I wonder if your config is messed up, and it's causing both issues. Can you attach your ~/.config/plasmashellrc file too? Thanks!

Also can you confirm that it still happens in Plasma 5.25.3, which was just released today?

Thank you!
Here you are:
https://pastebin.com/64Vhgrqy

Plasma 5.25.3 isn't in Arch repos yet but Im awaiting it to arrive soon.

I forgot to mention - my config is the same for years for the installation is the same too. Yesterday I restored from a three months old backup but the problem persists. There was no problems eith Plasma versions prior to 5.25.

Yes, the problem is still here with Plasma 5.25.3:
https://i.imgur.com/ra9NLxC.png

All your panels seem to have sane thickness values:


[PlasmaViews][Panel 1][Defaults]
thickness=32
 
[PlasmaViews][Panel 1][Horizontal0]
thickness=30
 
[PlasmaViews][Panel 1][Horizontal1024]
length=674
thickness=34
 
[PlasmaViews][Panel 1][Horizontal1280]
length=646
thickness=32
 
[PlasmaViews][Panel 1][Horizontal1920]
length=1001
thickness=32
 
[PlasmaViews][Panel 1][Horizontal2048]
thickness=30


What may be happening is that a race condition causes a panel that's on an inactive input to get inappropriately queried and then it returns an invalid number. Needs investigation by a multiscreen expert; CCing Marco.

Thank you.
I'm using sungle monitor setup though.

I thought "at monitor turn on" implied a second monitor. If you only have a single monitor, what are the circumstances under which the monitor is turned off that causes this to happen?

Just turn off the monitor from the button and the turn it on, nothing more :)

https://i.imgur.com/JduCDJg.jpg

Ah. So in that state, the system has gone from 1 output to 0 outputs. That seems relevant.

May I ask why you're turning off the screen when the system isn't sleeping?

Uh?
I turn off my PC only at nights. When I wake up I start the PC, working, gaming, reading etc., and when I have to go to eat or have some other work, I just turn the monitor off. I do this a lot of times a day.

Here is a video with the problem:
https://youtu.be/7Sgt9YShtfA
Why it hides the panel at all at monitor turn off? And why it matters for the DE if the monitor is on or off? I have all power savings turned off and still...
It's not 100% reproducible, when it desides it begins. Then I can turn on and turn off the monitor multiple times without problems. If I wait a minute or two, it may begin to have the problem again. With the same conditions, without any changes.

It matters very much if you go from 3 monitors to 2, or 2 monitors to 1, because in those cases, everything that was on the monitor that's now off needs to be handled somehow. Should it be moved to one of the existing monitors? Where? Should it be hidden? Depends on the thing.

However when going from 1 to 0, we don't have to do anything because the system becomes basically unusable. So I suspect we just need to add a special case for this in whatever part of the code handled removed screens--or fix the bug preventing it from working, if it already has such special handling.

I see. Thank you!

I don't know if this can be of any help but the panel hide and rearrange is triggered also at lowering resolution. For example, if I switch from 2040x1080 to any lower resolution, I have the ptoblem 100% reproducible. Something happened in 5.25. There was no such problem in previous versions.

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

Any chances this get fixed soon? It's annoyng as hell...

Submit a merge request directly and then it will be fixed ;)

Very funny...

I submitted a MR ages ago on a completely blind fix: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1756 but closed as I couldn't reproduce the behaviour in a test case.

It seems your C++ is built differently to what I was running against.

Looking through gcc's std_algo.h I can see
      __glibcxx_assert(!(__hi < __lo));

I'm on Arch and may be this is the problem?
Let's hope someone see your fix. Thank you!

*** This bug has been marked as a duplicate of bug 454064 ***

David Edmundson thank you for the fix!
Any chance this will backported to 5.25? I can't imagine we have to live with this until October 11.

I've asked in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1980#note_496153

Thank you very much, appreciated!

It seems nobody answers for backporting. What we can do? It crashes hundreds times a day and it is very frsutrating...

I've cherry-picked it to Plasma 5.25.5 but you'll still have to wait a few weeks since that will be released on October 6th. If you want the fix faster than that, you can compile Plasma yourself from the Plasma/5.25 branch, or you can ask your distro to backport https://invent.kde.org/plasma/plasma-workspace/-/commit/f33070a0d94fe7d62fa19fe9ab8864a719ec0ea1 now.

Thank you!

I want to ask something:
I just realized it rearranges the panel even on resolution change. For example I'm starting a DosBox game and when I exit, the panel gets rearranged. Will the fix for this issue will fix this too or I have to file a new bug?

Most likely not fixed with this change; I would recommend filing a new bug report about it.

Thank you, I'll do.

I can confirm the problem is fixed in 5.25.5. Thank you!