Created attachment 156162 [details]
Backtrace for plasmashell

Addendum: It could be that I perceived plasmashell as not crashed because I could see the panel, but upon further inspection it looks like plasmashell crashes, THEN my CPU temperature rises while usage exceeds 25% (checked via htop.)

This leaves a panel on my screen that I can't interact with, which I perceived as "still running, but my CPU is thinking really hard about something."

Scratch that, it's doing it again but I can still interact with my panel so it hadn't fully crashed yet (it just did while I was writing this). High CPU temperature, and saw about 11% CPU usage.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2612

Git commit 4649594aa95d601ac6449c9e8baf8201b28602c5 by Fushan Wen.
Committed on 12/02/2023 at 15:38.
Pushed by fusionfuture into branch 'master'.

klipper: store QImage and construct QPixmap only when necessary

The mime data from Wayland clipboard is not the exact same image, so two
image items are listed (first time restarting plasmashell). But after
images are saved to local, they have the same uuid again. So klipper
starts to become confused after the second time restarting plasmashell.

This is caused by QPixmap::from(QImage).toImage() erasing metadata in the
image, and KSystemClipboard will emit changed signal on Wayland, so
another identical image is added to clipboard.
Related: bug 465225, bug 465326, bug 464828
FIXED-IN: 5.27

M  +5    -5    klipper/historyimageitem.cpp
M  +2    -2    klipper/historyimageitem.h
M  +3    -4    klipper/historyitem.h

https://invent.kde.org/plasma/plasma-workspace/commit/4649594aa95d601ac6449c9e8baf8201b28602c5

Git commit 41ac399c39a653cac1d63b3f1913ed4eb2f0d2c3 by Fushan Wen.
Committed on 13/02/2023 at 00:29.
Pushed by fusionfuture into branch 'cherry-pick-4649594a'.

klipper: store QImage and construct QPixmap only when necessary

The mime data from Wayland clipboard is not the exact same image, so two
image items are listed (first time restarting plasmashell). But after
images are saved to local, they have the same uuid again. So klipper
starts to become confused after the second time restarting plasmashell.

This is caused by QPixmap::from(QImage).toImage() erasing metadata in the
image, and KSystemClipboard will emit changed signal on Wayland, so
another identical image is added to clipboard.
Related: bug 465225, bug 465326, bug 464828
FIXED-IN: 5.27


(cherry picked from commit 4649594aa95d601ac6449c9e8baf8201b28602c5)

M  +5    -5    klipper/historyimageitem.cpp
M  +2    -2    klipper/historyimageitem.h
M  +3    -4    klipper/historyitem.h

https://invent.kde.org/plasma/plasma-workspace/commit/41ac399c39a653cac1d63b3f1913ed4eb2f0d2c3

Git commit 89d1f0e07955427a083cbc5af34e0ae9fdcdaad4 by Fushan Wen.
Committed on 13/02/2023 at 00:46.
Pushed by fusionfuture into branch 'Plasma/5.27'.

klipper: store QImage and construct QPixmap only when necessary

The mime data from Wayland clipboard is not the exact same image, so two
image items are listed (first time restarting plasmashell). But after
images are saved to local, they have the same uuid again. So klipper
starts to become confused after the second time restarting plasmashell.

This is caused by QPixmap::from(QImage).toImage() erasing metadata in the
image, and Wayland clipboard is async, so another identical image is added
to clipboard.
Related: bug 465225, bug 465326, bug 464828
FIXED-IN: 5.27


(cherry picked from commit 4649594aa95d601ac6449c9e8baf8201b28602c5)

M  +5    -5    klipper/historyimageitem.cpp
M  +2    -2    klipper/historyimageitem.h
M  +3    -4    klipper/historyitem.h

https://invent.kde.org/plasma/plasma-workspace/commit/89d1f0e07955427a083cbc5af34e0ae9fdcdaad4

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

Still getting this bug in 5.27 (downloaded from Arch Linux's testing repo), is there anything else I can do to pinpoint the issue better?

This looks like a different bug. Reopened.

Created attachment 156247 [details]
plasmashell terminal output

I'm planning to reproduce this in a clean Plasma live environment sometime this week, whenever I can catch a breather, but I did try to see if the crash correlates with copying things, and it really does seem like that's what's going on. Shortly after I make a Spectacle screenshot (rectangle, copy to clipboard) this bug occurs.

I grabbed the terminal output and attached it, hopefully it has something helpful in it.
(The "kpipewire_logging" lines came from hovering my cursor over open applications on my task manager.)

```
QBuffer::writeData: Memory allocation error
libpng error: Write Error
```

This inplies out of memory, which should have been fixed by the commit. Are you sure you are using plasma-workspace from Arch testing repo?

Thread 56 (Thread 0x7fff818116c0 (LWP 31717) "Thread (pooled)"):
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
        tid = <optimized out>
        ret = 0
        pd = <optimized out>
        old_mask = {__val = {140737307944259}}
        ret = <optimized out>
#1  0x00007ffff52a0953 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffff5251ea8 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
        ret = <optimized out>
#3  0x00007ffff523b53d in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {140737307944259, 2664, 140737306514384, 14, 1, 10, 140735366108864, 2, 140737488343456, 140735357718528, 140737306521769, 140737307944128, 140737306522947, 140737307944128, 10, 140735366108864}}, sa_flags = -181852854, sa_restorer = 0x7ffff53f2680 <stderr>}
#4  0x00007ffff549a833 in __gnu_cxx::__verbose_terminate_handler() () at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
        terminating = true
        t = <optimized out>
#5  0x00007ffff54a6d0c in __cxxabiv1::__terminate(void (*)()) (handler=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:48
#6  0x00007ffff54a6d79 in std::terminate() () at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:58
#7  0x00007ffff589fbcc in  () at /usr/lib/libQt5Core.so.5
#8  0x00007ffff58a18d7 in  () at /usr/lib/libQt5Core.so.5
#9  0x00007ffff529ebb5 in start_thread (arg=<optimized out>) at pthread_create.c:444
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737306552560, -7065840038227385631, -232, 2, 140737488343456, 140735357718528, 7065607860234314465, 7065863832691368673}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#10 0x00007ffff5320d90 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Can you provide a backtrace with symbols for libQT5Core?

Created attachment 156262 [details]
More comprehensive backtrace for plasmashell

(In reply to Fushan Wen from comment #12)
> Are you sure you are using plasma-workspace from Arch testing repo?

Just double-checked, yes I am.

(In reply to David Redondo from comment #13)
> Can you provide a backtrace with symbols for libQT5Core?

Thanks! Still new to generating backtraces, now I've learned about another thing to look out for.
Uploaded a new backtrace with as many missing symbols as I could.

Thanks, pasting 

Thread 26 (Thread 0x7fff81e296c0 (LWP 8702) "Thread (pooled)"):
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
        tid = <optimized out>
        ret = 0
        pd = <optimized out>
        old_mask = {__val = {140737307944259}}
        ret = <optimized out>
#1  0x00007ffff52a0953 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffff5251ea8 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
        ret = <optimized out>
#3  0x00007ffff523b53d in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {140737307944259, 2664, 140737306514384, 14, 1, 2, 0, 0, 140737310297640, 140735372495488, 140735139571616, 0, 140736022425744, 140735364108288, 140737353991004, 140737309770754}}, sa_flags = -134353364, sa_restorer = 0x7ffff53f2680 <stderr>}
#4  0x00007ffff549a833 in __gnu_cxx::__verbose_terminate_handler() () at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
        terminating = true
        t = <optimized out>
#5  0x00007ffff54a6d0c in __cxxabiv1::__terminate(void (*)()) (handler=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:48
#6  0x00007ffff54a6d79 in std::terminate() () at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:58
#7  0x00007ffff589fbcc in qTerminate() () at global/qglobal.cpp:3382
#8  0x00007ffff58a18d7 in QThreadPrivate::start(void*) (arg=0x7fff9400cb10) at thread/qthread_unix.cpp:342
        __clframe = {__cancel_routine = 0x7ffff58e2520 <QThreadPrivate::finish(void*)>, __cancel_arg = 0x7fff9400cb10, __do_it = 1, __cancel_type = <optimized out>}
#9  0x00007ffff529ebb5 in start_thread (arg=<optimized out>) at pthread_create.c:444
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737306552560, 548654131098557183, -232, 0, 140736022425744, 140735364108288, -548817091165283585, -548633944005928193}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#10 0x00007ffff5320d90 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

This looks like your system is mixing old and new libraries.

I haven't gotten time to try a fresh Plasma live environment yet, but while using 5.26.90 I noticed that the same bug happens on my laptop which also runs Arch. Still happens on 5.27 there too.

(In reply to Fushan Wen from comment #16)
> This looks like your system is mixing old and new libraries.

That's super odd, I'm trying to figure out how I might go about fixing that because I've checked and all my libraries are up to date (Plasma, Frameworks, Qt.) Furthermore I only have official repositories enabled.

I know this isn't an advice forum, but would you happen to have any idea what I can try to prevent it from doing that?

> (In reply to Fushan Wen from comment #16)
>  This looks like your system is mixing old and new libraries.

Ok, finally had time to try this in Neon (both X11 and Wayland session) and as expected based on your comment, the problem is on my end. I'll need to figure out why both my Arch computers are having this issue. Nevertheless, I appreciate that you lended me your time.
I hope it's ok that I leave the status of the bug up to you, as I'm not sure how you'd rather close it.

Please retest on 5.27.1. I suspect Arch is still using the old tarball that does not contain the patch.

(In reply to Fushan Wen from comment #19)
> Please retest on 5.27.1. I suspect Arch is still using the old tarball that
> does not contain the patch.

No, we're not.

I found a fix.. I feel very silly now.

My klipperrc had this line in it: Version=5.26.90
I changed that to read Version=5.27.0, and now the issue is gone.