| Summary: | Plasma crash in Plasma::Applet::actions() | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Pavel Nedrigailov <pavel.nedr> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | a.nolting, bhush94, edoubrayrie, notmart, pavel.nedr, r.alonso.espana, raphael.cazenave |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.2.0 | ||
| Target Milestone: | 1.0 | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Pavel Nedrigailov
2015-02-16 13:39:57 UTC
Does your monitor physically turn itself off? This backtrace is showing that plasma is finding a new monitor. *** Bug 344783 has been marked as a duplicate of this bug. *** No response to my question in a month. Closing If you can give better steps to reproduce, that would really be useful. Hello David, please re-open this bug report. My respond may help you as I figured out that plasma crashes every time it does not get in time an answer from the attached monitor. To explain this, since the last updates for plasma-desktop and kwin on openSUSE yesterday the situation went better but not good. I played now a bit with Kscreen5 (what I initially suspected that) and NVIDIA Settings tool. First I uninstalled Kscreen5 and used only NVIDIA Settings to switch and expand my desktop. If I have my external monitor in standby, sometimes it wakes up if plasma try to expand the desktop but I tooks to long so plasma trys to fall back to it's initial settings and seem to to try to complain about no device detected. On other trys the monitor detects a signal at the DVI port and trys to sync on that but plasma seems not to process properly the communication at this point between the monitor and the graphics device and expand suddenly the desktop on the first screen (screen0) to the resolution of both internal and external monitor. Then the next try (all the time I ensure that the monitor is not in Power Save mode for better repsonse times) it expands the screen to both monitors (internal and external) but it corrupts the open gl memory and after a while plasma crashes. And at least it successfully expend the screen without any glitches until the laptop fell into a power save mode. Waking up the monitors results every time in crash of plasma with corrupting or not the memory. I figured out that if my Samsung Monitor is in power save and detects a signal on DVI port, it took some seconds to bring it up and have the signal synced. The same when monitor is up but without any signal and is searching all the ports for one. Additionally the monitor is in case of detecting a signal first shutting down all ports before it try to re-open the port again for syncing, which may look from plasmas perspective a new device is attached while it try's to bring the monitor up. Regards Alex Thanks I can confirm the issue, I just got this when undocking / redocking my laptop to a dock connected to two monitors. I have an Intel card, so this crash is not nvidia-only. I got a black screen with mouse only (a big empty black window) when dedocking prior to this docking crash. Not sure what to provide to help. (On a related note, about the "corrupts the open gl memory" mentioned above, with triangles randomly flickering on screen while moving the mouse: I get it when connecting an nvidia-powered laptop to same screen, so that separate issue may be specific to nvidia proprietary-driver) to complete the backtrace that's missing debug symbols:
Plasma::Applet::actions() is called in ShellCorona::addOutput()
at line 840 of plasma-workspace/shell/shellcorona.cpp
QAction *removeAction = containment->actions()->action("remove");
this means containment is invalid.
that instance (the one for the new monitor) is created some lines before,
Plasma::Containment *containment = createContainmentForActivity(m_activityController->currentActivity(), m_views.count());
so means that sometimes createContainmentForActivity() with some conditions, fails.
btw, on a proper debug build the backtrace would be a bit different, since there is an assert in createContainmentForActivity on containment being valid, and did never hit that as well.
cannot reproduce i tried both the cases when the containment for the new monitor was already present in the appletsrc file or the case where had to be created Maybe it's related to https://bugs.kde.org/show_bug.cgi?id=346378 (happens almost everytime after enabling or disabling screens on kscreen) ? * I'm using xf86-video-intel on Intel HD Graphics 4600. * Operating system: Archlinux x86_64 * plasmashell 5.2.2 * plasma-framework 5.9.0-1 Thread 1 in both backtraces looks pretty similar : "Plasma::Applet::actions() const () from /usr/lib/libKF5Plasma.so.5". Sorry I forgot a quicklink here to the trace: https://paste.kde.org/p6yngpoa9 *** Bug 346378 has been marked as a duplicate of this bug. *** Is it possible to install the suspected component with the debug flags on ArchLinux, to be able to give you an usefull stacktrace ? But i'm not sure wich component need to be installed with debug symbols. I have theses package that seems to be relative to plasma: ``` kdeplasma-addons-frameworks 5.2.2-1 plasma-desktop 5.2.2-3 plasma-framework 5.9.0-1 plasma-meta 5.2.0-5 plasma-nm 5.2.2-1 plasma-workspace 5.2.2-2 ``` And if you have any reproductible way to get the relatives sources and how to build them with debugs flags on ArchLinux, i am interested :) *** This bug has been marked as a duplicate of bug 343216 *** *** Bug 347747 has been marked as a duplicate of this bug. *** |