Bug 328007 - KWin crash when packing windows to the left
Summary: KWin crash when packing windows to the left
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.11.2
Platform: Ubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2013-11-24 12:14 UTC by Martin Nilsson
Modified: 2013-11-25 17:49 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.11.4


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Nilsson 2013-11-24 12:14:15 UTC
Application: kwin (4.11.2)
KDE Platform Version: 4.11.2
Qt Version: 4.8.4
Operating System: Linux 3.11.0-13-generic x86_64
Distribution: Ubuntu 13.10

-- Information about the crash:
- What I was doing when the application crashed:
Issuing quick tile window to the left or right on the other monitor, running a separate X server (I think, amdcccle says "Single display desktop (Multi-desktop)"). Does not crash every time, but often. There were no windows on the desktop that got this crash handler window.

- Unusual behavior I noticed:
KDE now hangs during startup (at the Kubuntu logo) when running both monitors from same GPU and a single X server. This is the reason for the multiple X servers I currently use.

- Custom settings of the application:
Installed AMDs beta drivers (Yeah, I know. Sorry) but they didn't work at all. Monitors went to sleep right after BIOS/POST/GRUB. Using revocery mode and a root console I removed the beta drivers and reinstalled fglrx from the repositories. I now get picture, but also the problem outlined in "Unusual behavior I noticed" above.

-- Backtrace:
Application: KWin (kwin), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fcd2c4307c0 (LWP 2114))]

Thread 3 (Thread 0x7fcd0e8d7700 (LWP 2127)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007fcd2af0606b in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#2  0x00007fcd2af060a9 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#3  0x00007fcd23867f6e in start_thread (arg=0x7fcd0e8d7700) at pthread_create.c:311
#4  0x00007fcd2bd1a9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 2 (Thread 0x7fcd0f2ef700 (LWP 2385)):
#0  0x00007fcd2bd12de3 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fcd260dd37b in qt_safe_select (nfds=12, fdread=0x7fcd080015d8, fdwrite=0x7fcd08001870, fdexcept=0x7fcd08001b08, orig_timeout=0x0) at kernel/qcore_unix.cpp:83
#2  0x00007fcd260e2904 in QEventDispatcherUNIXPrivate::doSelect (this=this@entry=0x7fcd08001420, flags=..., timeout=0x0) at kernel/qeventdispatcher_unix.cpp:223
#3  0x00007fcd260e2d02 in QEventDispatcherUNIX::processEvents (this=0x7fcd080008f0, flags=...) at kernel/qeventdispatcher_unix.cpp:937
#4  0x00007fcd260b15ef in QEventLoop::processEvents (this=this@entry=0x7fcd0f2eed70, flags=...) at kernel/qeventloop.cpp:149
#5  0x00007fcd260b18e5 in QEventLoop::exec (this=this@entry=0x7fcd0f2eed70, flags=...) at kernel/qeventloop.cpp:204
#6  0x00007fcd25fb088f in QThread::exec (this=this@entry=0x27e51f0) at thread/qthread.cpp:542
#7  0x00007fcd26092d13 in QInotifyFileSystemWatcherEngine::run (this=0x27e51f0) at io/qfilesystemwatcher_inotify.cpp:265
#8  0x00007fcd25fb2f2f in QThreadPrivate::start (arg=0x27e51f0) at thread/qthread_unix.cpp:338
#9  0x00007fcd23867f6e in start_thread (arg=0x7fcd0f2ef700) at pthread_create.c:311
#10 0x00007fcd2bd1a9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 1 (Thread 0x7fcd2c4307c0 (LWP 2114)):
[KCrash Handler]
#6  KWin::Workspace::slotWindowPackLeft (this=0x26efc70) at ../../kwin/placement.cpp:673
#7  0x00007fcd2c043d95 in KWin::Workspace::qt_static_metacall (_o=0x26efc70, _id=0, _a=0x7fffeaf57110, _c=<optimized out>) at ./workspace.moc:235
#8  0x00007fcd260c6a58 in QMetaObject::activate (sender=sender@entry=0x275b7c0, m=m@entry=0x7fcd25ef2de0 <QAction::staticMetaObject>, local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7fffeaf57110) at kernel/qobject.cpp:3539
#9  0x00007fcd25443a32 in QAction::triggered (this=this@entry=0x275b7c0, _t1=false) at .moc/release-shared/moc_qaction.cpp:277
#10 0x00007fcd25445403 in QAction::activate (this=0x275b7c0, event=<optimized out>) at kernel/qaction.cpp:1257
#11 0x00007fcd2a997646 in trigger (this=<optimized out>) at /usr/include/qt4/QtGui/qaction.h:218
#12 KGlobalAccelPrivate::_k_invokeAction (this=0x26efc70, componentUnique=..., actionUnique=..., timestamp=926992) at ../../kdeui/shortcuts/kglobalaccel.cpp:449
#13 0x00007fcd260c6a58 in QMetaObject::activate (sender=0x2751b10, m=m@entry=0x7fcd2ad74c00 <OrgKdeKglobalaccelComponentInterface::staticMetaObject>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7fffeaf57300) at kernel/qobject.cpp:3539
#14 0x00007fcd2aa97a19 in OrgKdeKglobalaccelComponentInterface::globalShortcutPressed (this=<optimized out>, _t1=..., _t2=..., _t3=926992) at kglobalaccel_component_interface.moc:164
#15 0x00007fcd2aa97bbc in OrgKdeKglobalaccelComponentInterface::qt_static_metacall (_o=0x2751b10, _id=_id@entry=0, _a=0x7fffeaf57580, _c=<optimized out>) at kglobalaccel_component_interface.moc:75
#16 0x00007fcd2aa98065 in qt_static_metacall (_a=0x7fffeaf57580, _id=0, _c=QMetaObject::InvokeMetaMethod, _o=0x2751b10) at kglobalaccel_component_interface.moc:129
#17 OrgKdeKglobalaccelComponentInterface::qt_metacall (this=0x2751b10, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fffeaf57580) at kglobalaccel_component_interface.moc:130
#18 0x00007fcd26443e36 in QDBusConnectionPrivate::deliverCall (this=0x2579cc0, object=0x2751b10, msg=..., metaTypes=..., slotIdx=5) at qdbusintegrator.cpp:951
#19 0x00007fcd260cadce in QObject::event (this=0x2751b10, e=<optimized out>) at kernel/qobject.cpp:1194
#20 0x00007fcd25449dfc in QApplicationPrivate::notify_helper (this=this@entry=0x2585d20, receiver=receiver@entry=0x2751b10, e=e@entry=0x3626250) at kernel/qapplication.cpp:4567
#21 0x00007fcd25450470 in QApplication::notify (this=this@entry=0x7fffeaf57e30, receiver=receiver@entry=0x2751b10, e=e@entry=0x3626250) at kernel/qapplication.cpp:4353
#22 0x00007fcd2a959a6a in KApplication::notify (this=0x7fffeaf57e30, receiver=0x2751b10, event=0x3626250) at ../../kdeui/kernel/kapplication.cpp:311
#23 0x00007fcd260b28bd in QCoreApplication::notifyInternal (this=0x7fffeaf57e30, receiver=receiver@entry=0x2751b10, event=event@entry=0x3626250) at kernel/qcoreapplication.cpp:946
#24 0x00007fcd260b5e1f in sendEvent (event=0x3626250, receiver=0x2751b10) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
#25 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x25301f0) at kernel/qcoreapplication.cpp:1570
#26 0x00007fcd260b62c3 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1463
#27 0x00007fcd254ec14c in sendPostedEvents () at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236
#28 QEventDispatcherX11::processEvents (this=0x2531ad0, flags=...) at kernel/qeventdispatcher_x11.cpp:75
#29 0x00007fcd260b15ef in QEventLoop::processEvents (this=this@entry=0x7fffeaf57ca0, flags=...) at kernel/qeventloop.cpp:149
#30 0x00007fcd260b18e5 in QEventLoop::exec (this=this@entry=0x7fffeaf57ca0, flags=...) at kernel/qeventloop.cpp:204
#31 0x00007fcd260b6e5b in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1218
#32 0x00007fcd2544834c in QApplication::exec () at kernel/qapplication.cpp:3828
#33 0x00007fcd2c063956 in kdemain (argc=3, argv=0x7fffeaf57f78) at ../../kwin/main.cpp:597
#34 0x00007fcd2bc41de5 in __libc_start_main (main=0x4006d0 <main(int, char**)>, argc=3, ubp_av=0x7fffeaf57f78, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffeaf57f68) at libc-start.c:260
#35 0x00000000004006fe in _start ()

Reported using DrKonqi
Comment 1 Thomas Lübking 2013-11-24 13:06:23 UTC
There's quite some oddity here.

1st, the backtrace ends in window packing - not quick tiling
2nd, unless Ubuntu is off by few lines, the crash occurs in

668	void Workspace::slotWindowPackLeft()
669	{
670	    if (active_client && active_client->isMovable())
671	        active_client->screen();
672	        active_client->packTo(packPositionLeft(active_client, active_client->geometry().left(), true),
673	                              active_client->y());
674	}

So it seems to happen on resolution of "active_client->y()", but "active_client->geometry().left()" had been resolved before.

NEVERTHELESS: there's a bug! (apparently by merge? - i hope so ;-)

671	        active_client->screen();

should not be there and detaches the active_client test from "active_client->packTo"

I assume that's the cause for the segfault here.

I altered the subject.
If you actually get crashes on quicktiling (and esp. on quick tiling to the right), please file them again - but i rather assume you assigned the wrong shortcut?
Comment 2 Martin Nilsson 2013-11-24 13:39:28 UTC
You are probably right about the tile vs. pack. I use them both frequently and for a vertically maximized single window they do pretty much the same thing.

Tested a bit more and the crash happens iff I pack a window against the desktop edge. Left or right doesn't matter. I haven't tried up or down, see next paragraph. In contrast, if the packed window hits anther window instead of the desktop edge then no crash occurs.

I just got a decoration-less dialog box telling me that KDE is unstable and was asked to to choose another window manager from a dropdown list only including KDE. I have since then lost all my panels and widgets from the crashing monitor. Guess KDE didn't come back any more. Haven't gotten the crash report since no matter how much I pack and tile windows on the other monitor, which still works just fine.
Comment 3 Thomas Lübking 2013-11-24 14:28:26 UTC
Git commit 52629d97c1648f6ea0190c81b14f7d9f0823f138 by Thomas Lübking.
Committed on 24/11/2013 at 13:21.
Pushed by luebking into branch 'KDE/4.11'.

remove false noop breaking branches
FIXED-IN: 4.11.4

M  +0    -1    kwin/placement.cpp

http://commits.kde.org/kde-workspace/52629d97c1648f6ea0190c81b14f7d9f0823f138
Comment 4 Thomas Lübking 2013-11-24 14:40:54 UTC
(In reply to comment #2)
> Tested a bit more and the crash happens iff I pack a window against the
> desktop edge. Left or right doesn't matter.
Ok, that's a different issue then - i cannot see why pack to right should crash (at all)

Can you please pack to right and post/attach the resulting backtrace?
(There might be some further oddity about the active window because of the multihead situation)

> including KDE. I have since then lost all my panels and widgets from the
> crashing monitor.
Means that plasma-desktop on that head crashed as well.
Sth. is fishy here.

> crash report since no matter how much I pack and tile windows on the other
> monitor, which still works just fine.

Humm? Global shortcuts are supposed to only work on _one_ screen... (kglobalaccel operates on only one screen)
Comment 5 Martin Nilsson 2013-11-25 17:35:01 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > Tested a bit more and the crash happens iff I pack a window against the
> > desktop edge. Left or right doesn't matter.
> Ok, that's a different issue then - i cannot see why pack to right should
> crash (at all)

You're right. There is a some delay between issuing the pack command and the crash report showing. This made me believe that the second pack of a PackLeft-PackRight pair was the cause when it really was the first one. Tiling never causes the crash. I attempted to experiment with up and down packing as well, but now the panels have gone missing again and the crash no longer happens no matter what I do. I guess I'll have to reboot to get them back, both the panels and the crashes.

(In reply to comment #4)
> (In reply to comment #2)
> > including KDE. I have since then lost all my panels and widgets from the
> > crashing monitor.
> Means that plasma-desktop on that head crashed as well.
> Sth. is fishy here.

Is there a way to restart it, just as seems to happen automatically after the first five or so crashes? I can still right-click the in the monitor with the missing panels and get the KDE menu with "Add widgets", "Leave...", "Run command" and such, but choosing "Run command" opens the runner text field on the monitor with the working desktop. Any applications I launch is opened on the working desktop.

(In reply to comment #4)
> (In reply to comment #2)
> > crash report since no matter how much I pack and tile windows on the other
> > monitor, which still works just fine.
> Humm? Global shortcuts are supposed to only work on _one_ screen...
> (kglobalaccel operates on only one screen)

That explains why my shortcuts doesn't always work. I have a primary monitor (left) where I do most of my work. This monitor is identified as Monitor 1 in amdcccle and is attached to the GPU passed to the "aticonfig --initial --adapter=1" command I issued after installing fglrx. The secondary monitor (right) was enabled later using amdcccle. Thus, per your comment above, global shortcuts works only from the primary (left) monitor. Issuing a Pack Left on the left monitor causes a crash report for KWin to open on the right monitor. All windows and panels and such continue undisturbed on the left monitor.

I do not know if packing windows on the right monitor would cause the left KWin to crash. Hard to test since global shortcuts doesn't work there and I don't know how else to issue a pack command.


It seems then that everything has been sorted out, despite my inaccurate statements in the beginning. Are there any further questions I can answer?

I'm using Kubuntu 13.10. Can I expect the update for this to show up in the regular updates, or will I have to wait for 14.04?
Comment 6 Thomas Lübking 2013-11-25 17:49:47 UTC
(In reply to comment #5)

> PackLeft-PackRight pair was the cause when it really was the first one.
> Tiling never causes the crash.
Very good (for that means the bug is fixed ;-)

> I can still right-click the in the monitor
> with the missing panels and get the KDE menu with "Add widgets", "Leave...",
> "Run command" and such, but choosing "Run command" opens the runner text
> field on the monitor with the working desktop. Any applications I launch is
> opened on the working desktop.
On the zaphod mode (multihead, independent X11 display - what you use atm.) clients cannot pass from one head to the other and without a special request (eg. "--display :1.0") applications will run on the head they're launched from.

However, plasma-desktop apparently didn't crash on that head, but simply moves the panels wherever.
You got to file a bug against plasma-desktop, but notice that the zaphod mode is not very well supported.
So in general i'd suggest on focusing why you cannot login with an xrandr multiscreen setup - might be a krandr (legacy) ./. kscreen2 (config daemon to use) issue.
Check installed packages and  in doubt uninstall everything that sounds like "krandr".

> It seems then that everything has been sorted out, despite my inaccurate
> statements in the beginning. Are there any further questions I can answer?
No, not really. Thanks for the kind offer - i'll come back on it in case =)
 
> I'm using Kubuntu 13.10. Can I expect the update for this to show up in the
> regular updates, or will I have to wait for 14.04?
I've no idea about ubuntus update policy, but the patch is in a minor release, so i'd expect it to be in regular updates.