Bug 353723 - plasmashell misbehaves/crashes on login with dual monitor setup
Summary: plasmashell misbehaves/crashes on login with dual monitor setup
Status: RESOLVED DUPLICATE of bug 351777
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.4.2
Platform: Fedora RPMs Linux
: NOR crash
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-09 15:46 UTC by Jetchko Jekov
Modified: 2015-10-14 15:01 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
crash report (8.65 KB, text/plain)
2015-10-09 15:50 UTC, Jetchko Jekov
Details
xrandr output (1.43 KB, text/plain)
2015-10-09 15:51 UTC, Jetchko Jekov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jetchko Jekov 2015-10-09 15:46:36 UTC
After upgrade to Fedora 22 plasmashell  misbehaves and crashes on login.
I have 2 external monitors connected (via docking station) to my notebook. SDDM shows login screen on both of them (ok, even on 3 of them, including notebook's display but usually I keep it closed). After entering credentials I see splash screen on both monitors. But after startup process finish, my right (mot primary) monitor stays black. No shell is running on it. There is no reaction to RMB (no menu pops up). But its active as I can move window to it. And there is no crash detected at this time. If I do 'xrandr --output HDMI2 --off; xrandr --output HDMI2 --auto --right-of DP1" (HDMI2 is the connection to the misbehaving monitor) plasma shell crashes and after it restarts everything seems to be working properly (except that position of all my windows are reset back to screen 0)

Reproducible: Always

Steps to Reproduce:
1. Login (right monitor is black)
2. xrandr --output HDMI2 --off
3. xrandr --output HDMI2 --auto --right-of DP1 (plasmashell crashes at this point) 



updates-testing repository is enabled
plasma-workspace-5.4.2-4.fc22.x86_64
plasma-workspace-libs-5.4.2-4.fc22.x86_64
kscreen-5.4.2-1.fc22.x86_64
libkscreen-qt5-5.4.2-1.fc22.x86_64
libkscreen-1.0.5-2.fc22.x86_64
kf5-plasma-5.14.0-1.fc22.x86_64
Comment 1 Jetchko Jekov 2015-10-09 15:50:16 UTC
Created attachment 94916 [details]
crash report

Attaching the crash report from drkonqi
Comment 2 Jetchko Jekov 2015-10-09 15:51:37 UTC
Created attachment 94917 [details]
xrandr output
Comment 3 Jetchko Jekov 2015-10-09 15:52:38 UTC
I am happy to provide any additional information if necessary
Comment 4 Jetchko Jekov 2015-10-12 15:58:29 UTC
Little bit more info if its on any use:

Today I tried to automate my workaround via executing:
xrandr --output HDMI2 --off && xrandr --output HDMI2 --auto --right-of DP1

And this *DID NOT* help,  the monitor stays black but active.
I had to put sleep 1 in between xrandr invocations to make it work , i.e:
xrandr --output HDMI2 --off && sleep 1 && xrandr --output HDMI2 --auto --right-of DP1

whats more, if I execute 1st sequence (without sleep) when shell is running on both monitors I again get blank monitor, working state gets restored after sequence with sleep included and plasmashell is not crashing in this situation.
Comment 5 Marco Martin 2015-10-14 14:59:29 UTC
pasting bt inline
Thread 1 (Thread 0x7f87bbe5e900 (LWP 10170)):
[KCrash Handler]
#5  0x00007f87b9a204e6 in Plasma::Applet::actions() const () at /lib64/libKF5Plasma.so.5
#6  0x0000000000455139 in ShellCorona::addOutput(QSharedPointer<KScreen::Output> const&) (this=this@entry=0x24eb7a0, output=...) at ../../shell/shellcorona.cpp:862
#7  0x00000000004552bf in ShellCorona::outputEnabledChanged() (this=0x24eb7a0) at ../../shell/shellcorona.cpp:756
#8  0x00007f87b469afe7 in QMetaObject::activate(QObject*, int, int, void**) () at /lib64/libQt5Core.so.5
#9  0x00007f87bacdff97 in KScreen::Output::apply(QSharedPointer<KScreen::Output> const&) () at /lib64/libKF5Screen.so.6
#10 0x00007f87baccbbde in KScreen::Config::apply(QSharedPointer<KScreen::Config> const&) () at /lib64/libKF5Screen.so.6
#11 0x00007f87bacd2c49 in KScreen::ConfigMonitor::Private::updateConfigs(QSharedPointer<KScreen::Config> const&) () at /lib64/libKF5Screen.so.6
#12 0x00007f87bacd4f39 in KScreen::ConfigMonitor::Private::edidReady(QDBusPendingCallWatcher*) () at /lib64/libKF5Screen.so.6
#13 0x00007f87b469afe7 in QMetaObject::activate(QObject*, int, int, void**) () at /lib64/libQt5Core.so.5
#14 0x00007f87b546674f in QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) () at /lib64/libQt5DBus.so.5
#15 0x00007f87b5467e25 in QDBusPendingCallWatcher::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () at /lib64/libQt5DBus.so.5
#16 0x00007f87b469c021 in QObject::event(QEvent*) () at /lib64/libQt5Core.so.5
#17 0x00007f87b5c224ac in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#18 0x00007f87b5c27976 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#19 0x00007f87b466c61b in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#20 0x00007f87b466ea16 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /lib64/libQt5Core.so.5
#21 0x00007f87b46c2983 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () at /lib64/libQt5Core.so.5
#22 0x00007f87aea36a8a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#23 0x00007f87aea36e20 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#24 0x00007f87aea36ecc in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#25 0x00007f87b46c2d8f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#26 0x00007f87b4669daa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#27 0x00007f87b4671e6c in QCoreApplication::exec() () at /lib64/libQt5Core.so.5
#28 0x00000000004302c3 in main(int, char**) (argc=2, argv=<optimized out>) at ../../shell/main.cpp:176
Comment 6 Marco Martin 2015-10-14 15:01:03 UTC

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