SUMMARY After some time playing music with Elisa, opening the media player applet in the system tray and pressing "skip" occasionally results in a plasma freezing, before crashing, and then automatically restarting. STEPS TO REPRODUCE 1. Play music for a while (hours?) (presumably any player works) 2. Open the media player applet 3. Skip to the next track OBSERVED RESULT The next track button goes into its depressed state (i.e. blue background), and does not come back, all panels freeze. EXPECTED RESULT The next song is skipped to, nothing freezes. SOFTWARE/OS VERSIONS Operating System: Fedora 34 KDE Plasma Version: 5.22.2 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.2 Kernel Version: 5.12.12-300.fc34.x86_64 (64-bit) Graphics Platform: X11 Processors: 32 × AMD Ryzen 9 3950X 16-Core Processor Memory: 62.8 GiB of RAM Graphics Processor: AMD NAVY_FLOUNDER ADDITIONAL INFORMATION I tried to attach gdb to get a better idea of where this is happening, but the auto recovery kicked in before I could get everything in place. The crash reporter did show as well, but before I could finish filing a report, the auto restart killed the crash reporter (I'll file a separate bug for this if one is not already present).
I'll add I also observed this in 5.21.x; I waited to report until Fedora was updated to 5.22.x in case it was already resolved.
From a media player POV, we need a backtrace for this to be actionable. >I tried to attach gdb to get a better idea of where this is happening, but the auto recovery kicked in before I could get everything in place. If you can reproduce reliably, you can start it under "gdb --args plasmashell --replace" This would prevent systemd killing the subgroup on restart. You can also find a backtrace in coredumpctl
(In reply to David Edmundson from comment #2) > From a media player POV, we need a backtrace for this to be actionable. > > >I tried to attach gdb to get a better idea of where this is happening, but the auto recovery kicked in before I could get everything in place. > > If you can reproduce reliably, you can start it under "gdb --args > plasmashell --replace" > > This would prevent systemd killing the subgroup on restart. > > You can also find a backtrace in coredumpctl Sadly it's anything but reliable... I'll try to get something useful regardless. It would be ideal if the crash reporter wasn't forcefully closed.
Created attachment 139745 [details] Log of thread backtraces
Alright I got GDB attached, and hopefully I've got some useful information now (backtrace of all threads has already been attached). Beyond that plasmashell thread seems to be stuck in a loop here trying to figure out where to allocate a page (though this may be unrelated/just statistically significantly reentered hot logic): jsruntime/qv4persistent.cpp │ 196 Value *PersistentValueStorage::allocate() │ 197 { │ 198 Page *p = static_cast<Page *>(firstPage); │ 199 while (p) { │ >200 if (p->header.freeList != -1) │ 201 break; │ 202 p = p->header.next; │ 203 } │ 204 if (!p) │ 205 p = allocatePage(this); │ 206 │ 207 Value *v = p->values + p->header.freeList; │ 208 p->header.freeList = v->int_32();
Changing this back to reported as the requested info was provided. Also noting I switched from Elisa to Rhythmbox and this issue stopped happening. I suspect Elisa is doing something unusual that Plasma is handling badly.
Which thread is crashing? It's not clear. We don't need to see all threads, just the crashing one.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!