Bug 464334 - Plasmashell crash when primary monitor disconnected
Summary: Plasmashell crash when primary monitor disconnected
Status: RESOLVED WORKSFORME
Alias: None
Product: plasmashell
Classification: Plasma
Component: generic-multiscreen (show other bugs)
Version: master
Platform: Other Linux
: NOR crash
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-01-15 18:27 UTC by Steven Robbins
Modified: 2023-03-19 17:48 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
signature.asc (833 bytes, application/pgp-signature)
2023-02-05 05:20 UTC, Steven Robbins
Details
New crash information added by DrKonqi (7.15 KB, text/plain)
2023-03-19 17:48 UTC, Zac Willoh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steven Robbins 2023-01-15 18:27:12 UTC
SUMMARY
***
Plasmashell crash when primary monitor (of a two monitor system) disconnected.
Discovered this while using KDE Neon 20230115-1117 in attempt to test bug 460341.
Sadly, there was no usable backtrace - but the crash handler indicated that PlasmaShell crashed with seg fault.
***


STEPS TO REPRODUCE
1. Attach two monitors.
2. Boot KDE Neon 20230115-1117 live image
    - both monitors are enabled
3. Disconnect the primary monitor (using an HDMI switch)

OBSERVED RESULT

Crash handler reported that plasmashell exited with segfault.

EXPECTED RESULT

No crash.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: KDE Neon 20230115-1117 live ISO image

ADDITIONAL INFORMATION

I switched the primary to the other monitor and repeated.  There was no crash in the situation that the "non primary" monitor was the one disconnected.
Comment 1 Nate Graham 2023-01-15 18:31:12 UTC
Can you attach a backtrace of the creah please?
Comment 2 Steven Robbins 2023-01-15 19:34:12 UTC
On Sunday, January 15, 2023 12:31:12 P.M. CST you wrote:
> https://bugs.kde.org/show_bug.cgi?id=464334
> 
> Nate Graham <nate@kde.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> Status|REPORTED                    |NEEDSINFO
>                  CC|                            |nate@kde.org
>          Resolution|---                         |BACKTRACE
> 
> --- Comment #1 from Nate Graham <nate@kde.org> ---
> Can you attach a backtrace of the creah please?

According to the crash handler, there was no usable backtrace.
Comment 3 Nate Graham 2023-01-15 20:24:01 UTC
Maybe you can get one yourself using `coredumpctl`? See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl
Comment 4 Bug Janitor Service 2023-01-30 05:06:48 UTC
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!
Comment 5 Steven Robbins 2023-01-31 20:05:41 UTC
As noted initially, the kde neon boot disc did not provide a backtrace. 

However, the steps to reproduce are trivial enough that I expect the developer is able to get the backtrace themselves.
Comment 6 Nate Graham 2023-02-02 22:00:07 UTC
Multi-monitor bugs are unfortunately never trivial to reproduce due to differences in hardware--GPU make, model, and driver version; physical connector of the monitor; make, model, and manufacturer of the monitor; and so on.

We're going to need a backtrace to debug this. Can you get one?
Comment 7 Steven Robbins 2023-02-03 04:21:27 UTC
Core was generated by `/usr/bin/plasmashell --no-respawn'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=140269930528384) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
[Current thread is 1 (Thread 0x7f932361be80 (LWP 2462))]
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=11, threadid=140269930528384) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=11, threadid=140269930528384) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140269930528384, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
#3  0x00007f932788d476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
#4  0x00007f9329f4105d in KCrash::defaultCrashHandler(int) () from /lib/x86_64-linux-gnu/libKF5Crash.so.5
#5  <signal handler called>
#6  0x00005643da751644 in ?? ()
#7  0x00005643da76c4cf in ?? ()
#8  0x00007f9327f910d4 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007f9327f9515e in QTimer::timeout(QTimer::QPrivateSignal) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007f9327f869ff in QObject::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007f9328c61793 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x00007f9327f5907a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x00007f9327fb1e0b in QTimerInfoList::activateTimers() () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x00007f9327fb2754 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007f93268f5d3b in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007f932694a6c8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007f93268f33e3 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007f9327fb2ad8 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x00007f9327f5799b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007f9327f5ff34 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x00005643da73fa8b in ?? ()
#22 0x00007f9327874d90 in __libc_start_call_main (main=main@entry=0x5643da73eb70, argc=argc@entry=2, argv=argv@entry=0x7fff45400258)
    at ../sysdeps/nptl/libc_start_call_main.h:58
#23 0x00007f9327874e40 in __libc_start_main_impl (main=0x5643da73eb70, argc=2, argv=0x7fff45400258, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fff45400248) at ../csu/libc-start.c:392
#24 0x00005643da73fbb5 in ?? ()
Comment 8 Nate Graham 2023-02-05 04:04:50 UTC
Thanks! Unfortunately what we need is likely in here:

#6  0x00005643da751644 in ?? ()
#7  0x00005643da76c4cf in ?? ()

Can you install debug symbols for Plasma and KScreen and get a new backtrace?
Comment 9 Steven Robbins 2023-02-05 05:20:32 UTC
Created attachment 155950 [details]
signature.asc

On Saturday, February 4, 2023 10:04:50 P.M. CST you wrote:
> https://bugs.kde.org/show_bug.cgi?id=464334
> 
> Nate Graham <nate@kde.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> Status|REPORTED                    |NEEDSINFO
>          Resolution|---                         |BACKTRACE
> 
> --- Comment #8 from Nate Graham <nate@kde.org> ---
> Thanks! Unfortunately what we need is likely in here:
> 
> #6  0x00005643da751644 in ?? ()
> #7  0x00005643da76c4cf in ?? ()
> 
> Can you install debug symbols for Plasma and KScreen and get a new
> backtrace?

No, sorry.

There's something goofy with the KDE neon DVD.  It takes literally 30+ minutes 
to boot and makes my DVD drive sound like it's going to break.  I'm not doing 
this a third time.
Comment 10 Nate Graham 2023-02-06 16:36:43 UTC
Then there's no way for us to investigate and fix this issue, sorry. :/
Comment 11 Steven Robbins 2023-02-07 02:58:50 UTC
On Monday, February 6, 2023 10:36:43 A.M. CST you wrote:
> https://bugs.kde.org/show_bug.cgi?id=464334
> 
> Nate Graham <nate@kde.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> Resolution|BACKTRACE                   |WORKSFORME
>              Status|NEEDSINFO                   |RESOLVED
> 
> --- Comment #10 from Nate Graham <nate@kde.org> ---
> Then there's no way for us to investigate and fix this issue, sorry. :/

It would be good to at least document in this bug whether any developer even 
attempted to replicate.
Comment 12 Nate Graham 2023-02-07 03:38:37 UTC
I attempted to reproduce the issue with an external HDMI monitor plugged into my laptop that was made the primary, and unplugged it. No crashes after 5 attempts.
Comment 13 Andrew Hakman 2023-02-10 07:11:24 UTC
I am also having this same bug after updating Debian SID recently.

I routinely lock my session, and then turn off my monitors, and when I turn off the primary monitor, kded5 crashes / takes lots of CPU. When I turn my monitors back on later, the lock screen is stuck at the time I turned off the monitors last time, and nothing is responding.

I have to manually kill all the kded5 processes and restart some combination of kwin, kded5, and plasmashell from a virtual tty to sometimes get my session back.

Not sure if it's useful or not, but my 2 monitors are different resolutions (1 is 1920x1080, the other is 1920x1200) - this seems to cause much weird behavior in plasma / kwin / something, but I never had this crash on turning monitors off until very recently.
Comment 14 Andrew Hakman 2023-02-10 07:15:14 UTC
Oh, also, even when I do manage to get my session back, the second monitor stays disconnected and not detected in display settings. Sometimes switching between applications will magically bring it back, sometimes starting to play video in mplayer will bring it back, and sometimes doing all of that doesn't. It's very non-deterministic.
Comment 15 Andrew Hakman 2023-02-10 07:17:50 UTC
(In reply to Andrew Hakman from comment #14)
> Oh, also, even when I do manage to get my session back, the second monitor
> stays disconnected and not detected in display settings. Sometimes switching
> between applications will magically bring it back, sometimes starting to
> play video in mplayer will bring it back, and sometimes doing all of that
> doesn't. It's very non-deterministic.

Oh, and apparently sometimes closing windows will bring it back. I thought I was going to have to reboot to recover it this time, started closing windows, and after closing one, the second monitor was re detected (and the menu and task switcher came back at the same time)
Comment 16 Nate Graham 2023-02-12 16:22:04 UTC
Andrew, please submit a new bug report and make sure to include a backtrace of the crash with debug symbols. Without that, there's no way to know if your issue is the same as this one. Thanks!
Comment 17 Zac Willoh 2023-03-19 17:48:00 UTC
Created attachment 157424 [details]
New crash information added by DrKonqi

plasmashell (5.25.5) using Qt 5.15.6

On system start, an external HDMI switcher was used to switch away from the primary monitor. On return, when the HDMI switch reselected the system's primary monitor output, Plasma crashed.

-- Backtrace (Reduced):
#3  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#4  0x00007f7fda7f4859 in __GI_abort () at abort.c:79
#5  0x00007f7fdac44bd9 in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007f7fdac43fe5 in qt_assert(char const*, char const*, int) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x000055dcf2b53b3c in ScreenPool::handleScreenRemoved (this=0x55dcf2f3a860, screen=0x55dcf2e7e0e0) at /tmp/git-sources/plasma-workspace/shell/screenpool.cpp:437