If Canonicals Qt isn't too much patched, it crashes while disconnecting senders... pretty deep in the QObject deconstructor.

Can you reproduce this?

No I cannot reproduce this at will.  However the crash occurs quite often: I had 5 disks to partition (and did several experiments on one of them) and kwin crashed 3 times.

Whenever it crashes, attach the new backtrace here.
(The original one looks a bit spurious, so it could be do to something else corrupting memory or so - we'd need to know whether the condition will always lead to this particular failing code path)

FYI: the crash happens when an upmapped window closes itself - eg. there maybe a tooltip on the "Apply changes" button that triggers this? (Never used gparted)

Today kwin (4.11.3) crashed again while  running synaptic over ssh.  Bugzilla did not allow me to report this bug because it does not know about KDE 4.11.3 yet.  Since both crashes seem to be related, I am posting the new report to this bug...

Created attachment 83467 [details]
Another crash with complete backtrace

Here is the report.

Note that this bug is very similar to bug #323701.

All crashes have the same pattern: running an application on a remote system over ssh.  The concerned applications are synaptic, virt-manager and gparted.  In all cases the remote applications:
 - run on a Debian wheezy system (not the same, though)
 - are GTK2 or GTK3 applications
In all cases the kwin crash occurs on my laptop which is an Ubuntu system.  The network between my laptop and the remote host is not always the same (Ethernet, Wifi, Wifi+ADSL).

This bug is very much likely ultimately identical to bug #323701, yes. The recent backtrace there matches the first backtrace here.

The new backtrace here is different.
It might be a trace, though Ubuntu has a loooong record of bugs that start by "I updated packages", "I was using synaptic", "I was using adapt manager" ... ie. it crashes random stuff when you update packages (we came to believe that their installer truncates files)

Now, let's assume it did not happen because of a garbled library on disk:
1. I assume you're using either the aurorae (themes you installed by clicking "get more themes") or plastik decoration?
2. Is it reproducible with the oxygen or decoration laptop as well?


-------------
#23 QDeclarativePrivate::QDeclarativeElement<QDeclarativeRectangle>::~QDeclarativeElement (this=0x3cc7090, __in_chrg=<optimized out>) at ../../include/QtDeclarative/../../src/declarative/qml/qdeclarativeprivate.h:87
#24 0x00007f44b95dadae in QGraphicsItem::~QGraphicsItem (this=0x3c48260, __in_chrg=<optimized out>) at graphicsview/qgraphicsitem.cpp:1493
#25 0x00007f44bef1f482 in ~QGraphicsObject (this=0x3c48250, __in_chrg=<optimized out>) at ../../include/QtGui/../../src/gui/graphicsview/qgraphicsitem.h:547
#26 QDeclarativeItem::~QDeclarativeItem (this=0x3c48250, __in_chrg=<optimized out>) at graphicsitems/qdeclarativeitem.cpp:1664
#27 0x00007f44beee6e96 in ~QDeclarativeElement (this=0x3c48250, __in_chrg=<optimized out>) at ../../include/QtDeclarative/../../src/declarative/qml/qdeclarativeprivate.h:87
#28 QDeclarativePrivate::QDeclarativeElement<QDeclarativeItem>::~QDeclarativeElement (this=0x3c48250, __in_chrg=<optimized out>) at ../../include/QtDeclarative/../../src/declarative/qml/qdeclarativeprivate.h:87
#29 0x00007f44b9ca3e08 in QObject::event (this=0x3c48250, e=<optimized out>) at kernel/qobject.cpp:1175

To test the memory corruption hypothesis, I ran kwin with valgrind. I also managed to get a segfault while running a remote virt-manager application. The report is very noisy with seemingly harmless errors (invalid reads, ...). However this one is more worrisome:

==22214== Invalid write of size 8
==22214==    at 0x52A2E73: getaddrinfo (getaddrinfo.c:2719)
==22214==    by 0x4EA085A: QtConcurrent::StoredFunctorCall4<int, int (*)(char const*, char const*, addrinfo const*, addrinfo**), QByteArray, char const*, addrinfo*, addrinfo**>::runFunctor() (qtconcurrentstoredfunctioncall.h:876)
==22214==    by 0x4EA1D20: QtConcurrent::RunFunctionTask<int>::run() (qtconcurrentrunbase.h:106)
==22214==    by 0xADD77AD: QThreadPoolThread::run() (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.4)
==22214==    by 0xADE3F2E: QThreadPrivate::start(void*) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.4)
==22214==    by 0xD6EDF6D: start_thread (pthread_create.c:311)
==22214==    by 0x52CC9CC: clone (clone.S:113)
==22214==  Address 0x26a604b8 is 40 bytes inside a block of size 72 free'd
==22214==    at 0x4C2BADC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22214==    by 0xAEFA307: QObjectPrivate::deleteChildren() (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.4)
==22214==    by 0xAEFC8AE: QObject::~QObject() (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.4)
==22214==    by 0x4E9F660: KWin::ClientMachine::~ClientMachine() (client_machine.cpp:171)
==22214==    by 0xAEFA307: QObjectPrivate::deleteChildren() (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.4)
==22214==    by 0xAEFC8AE: QObject::~QObject() (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.4)
==22214==    by 0x4F1B5E8: KWin::Deleted::~Deleted() (deleted.cpp:48)
==22214==    by 0x4F1B7A8: KWin::Deleted::~Deleted() (deleted.cpp:55)
==22214==    by 0xAEFBE07: QObject::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.4)
==22214==    by 0xB413DFB: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.4)
==22214==    by 0xB41A46F: QApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.4)
==22214==    by 0x6655A69: KApplication::notify(QObject*, QEvent*) (kapplication.cpp:311)

And there is this error that should probably be looked closely:

file:///usr/lib/kde4/imports/org/kde/kwin/decoration/ButtonGroup.qml:86: RangeError: Maximum call stack size exceeded.

Created attachment 83468 [details]
valgrind log

On 10/11/2013 12:48, Thomas Lübking wrote:

> It might be a trace, though Ubuntu has a loooong record of bugs that start by
> "I updated packages", "I was using synaptic", "I was using adapt manager" ...
> ie. it crashes random stuff when you update packages (we came to believe that
> their installer truncates files)

I was not updating my system when those crashes happened.

> Now, let's assume it did not happen because of a garbled library on disk:

This can be verified:

$ debsums kde-window-manager
/usr/bin/kwin                                                                
OK
/usr/bin/kwin_gles                                                           
OK
/usr/lib/kde4/kwin4_effect_builtins.so                                       
OK
/usr/lib/kde4/kwin4_effect_gles_builtins.so                                  
OK
/usr/lib/kde4/libkdeinit/libkdeinit4_kwin.so                                 
OK
/usr/lib/kde4/libkdeinit/libkdeinit4_kwin_gles.so                            
OK
/usr/share/doc/kde-window-manager/CONFIGURING                                
OK
/usr/share/doc/kde-window-manager/README.Debian                              
OK
/usr/share/doc/kde-window-manager/changelog.Debian.gz                        
OK
/usr/share/doc/kde-window-manager/copyright                                  
OK
/usr/share/lintian/overrides/kde-window-manager                              
OK

I am also checking all packages on my system, just to be sure...

> 1. I assume you're using either the aurorae (themes you installed by clicking
> "get more themes") or plastik decoration?

I am using the "Plastik" decoration indeed.
> 2. Is it reproducible with the oxygen or decoration laptop as well?

Yes (with oxygen).  Here is yet another 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 0x7fa7205347c0 (LWP 22255))]


Thread 4 (Thread 0x7fa702a12700 (LWP 22260)):

#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

#1 0x00007fa71ef0b06b in QTWTF::TCMalloc_PageHeap::scavengerThread
(this=0x7fa71f208f00 <QTWTF::pageheap_memory>) at
../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:2359

#2 0x00007fa71ef0b0a9 in QTWTF::TCMalloc_PageHeap::runScavengerThread
(context=<optimized out>) at
../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:1464

#3 0x00007fa7178bdf6e in start_thread (arg=0x7fa702a12700) at
pthread_create.c:311

#4 0x00007fa71fd199cd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113


Thread 3 (Thread 0x7fa703429700 (LWP 26827)):

#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238

#1 0x00007fa719fea3e4 in wait (time=30000, this=0x1980ad0) at
thread/qwaitcondition_unix.cpp:84

#2 QWaitCondition::wait (this=<optimized out>,
mutex=mutex@entry=0x1980a78, time=30000) at
thread/qwaitcondition_unix.cpp:158

#3 0x00007fa719fdd8a5 in QThreadPoolThread::run (this=0x2b741e0) at
concurrent/qthreadpool.cpp:141

#4 0x00007fa719fe9f2f in QThreadPrivate::start (arg=0x2b741e0) at
thread/qthread_unix.cpp:338

#5 0x00007fa7178bdf6e in start_thread (arg=0x7fa703429700) at
pthread_create.c:311

#6 0x00007fa71fd199cd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113


Thread 2 (Thread 0x7fa700dbf700 (LWP 26828)):

#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238

#1 0x00007fa719fea3e4 in wait (time=30000, this=0x1980ad0) at
thread/qwaitcondition_unix.cpp:84

#2 QWaitCondition::wait (this=<optimized out>,
mutex=mutex@entry=0x1980a78, time=30000) at
thread/qwaitcondition_unix.cpp:158

#3 0x00007fa719fdd8a5 in QThreadPoolThread::run (this=0x188e1e0) at
concurrent/qthreadpool.cpp:141

#4 0x00007fa719fe9f2f in QThreadPrivate::start (arg=0x188e1e0) at
thread/qthread_unix.cpp:338

#5 0x00007fa7178bdf6e in start_thread (arg=0x7fa700dbf700) at
pthread_create.c:311

#6 0x00007fa71fd199cd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113


Thread 1 (Thread 0x7fa7205347c0 (LWP 22255)):

[KCrash Handler]

#6 QObject::~QObject (this=0x1ca56e0, __in_chrg=<optimized out>) at
kernel/qobject.cpp:915

#7 0x00007fa72004be89 in KWin::Client::~Client (this=0x1ca56e0,
__in_chrg=<optimized out>) at ../../kwin/client.cpp:242

#8 0x00007fa72004e525 in deleteClient (c=0x1ca56e0) at
../../kwin/client.cpp:247

#9 KWin::Client::releaseWindow (this=this@entry=0x1ca56e0,
on_shutdown=on_shutdown@entry=false) at ../../kwin/client.cpp:316

#10 0x00007fa720069faa in KWin::Client::unmapNotifyEvent
(this=0x1ca56e0, e=<optimized out>) at ../../kwin/events.cpp:595

#11 0x00007fa72006c0cb in KWin::Client::windowEvent (this=0x1ca56e0,
e=e@entry=0x7fffcae1d870) at ../../kwin/events.cpp:451

#12 0x00007fa72006d6ff in KWin::Workspace::workspaceEvent
(this=0x188e000, e=e@entry=0x7fffcae1d870) at ../../kwin/events.cpp:164

#13 0x00007fa720061a70 in KWin::Application::x11EventFilter
(this=0x7fffcae1dc60, e=0x7fffcae1d870) at ../../kwin/main.cpp:422

#14 0x00007fa7194ef42c in qt_x11EventFilter (ev=0x7fffcae1d870) at
kernel/qapplication_x11.cpp:441

#15 0x00007fa7194ffc50 in QApplication::x11ProcessEvent
(this=0x7fffcae1dc60, event=event@entry=0x7fffcae1d870) at
kernel/qapplication_x11.cpp:3458

#16 0x00007fa719529290 in QEventDispatcherX11::processEvents
(this=0x1786290, flags=...) at kernel/qeventdispatcher_x11.cpp:132

#17 0x00007fa71a0e85ef in QEventLoop::processEvents
(this=this@entry=0x7fffcae1dad0, flags=...) at kernel/qeventloop.cpp:149

#18 0x00007fa71a0e88e5 in QEventLoop::exec
(this=this@entry=0x7fffcae1dad0, flags=...) at kernel/qeventloop.cpp:204

#19 0x00007fa71a0ede5b in QCoreApplication::exec () at
kernel/qcoreapplication.cpp:1218

#20 0x00007fa71948534c in QApplication::exec () at
kernel/qapplication.cpp:3828

#21 0x00007fa720062956 in kdemain (argc=3, argv=0x7fffcae1dda8) at
../../kwin/main.cpp:597

#22 0x00007fa71fc40de5 in __libc_start_main (main=0x4006d0 <main(int,
char**)>, argc=3, ubp_av=0x7fffcae1dda8, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffcae1dd98) at libc-start.c:260

#23 0x00000000004006fe in _start ()

Can you compile a patch?

My wild guess and dislike is that kde-workspace/kwin/client_machine.cpp:71ff GetAddrInfo::~GetAddrInfo() performs async m_watcher->cancel(); and m_ownAddressWatcher->cancel(); before the parenting deconstructor (QObject) will delete those and while they may perform the cancel.

There're two basic concerns.

a) the "canceled" signal is bound to "deleteLater"
b) the cancel is asynchronous

one of those *might* cause the crash.

ad a)
cancel might be emitted from the ~GetAddrInfo() but the connection to the self deleteLater() is not broken before the inherited ~QObject() is called; might generate recursion.

ad b)
QFutureWatcher::cancel() might be still processed (it's another thread) while the inherited ~QObject() deletes the FutureWatcher - no idea what that might imply.

For a)
it might be sufficient to perform
connect(m_watcher, SIGNAL(canceled()), SLOT(deleteLater()), Qt::QueuedConnection);
connect(m_ownAddressWatcher, SIGNAL(canceled()), SLOT(deleteLater()), Qt::QueuedConnection);
in the constructor

Otherwise a dedicated
disconnect(m_watcher, SIGNAL(canceled()), SLOT(deleteLater()));
disconnect(m_ownAddressWatcher, SIGNAL(canceled()), SLOT(deleteLater()));

on top of the ~GetAddrInfo() should do.

For b)
injecting
m_watcher->waitForFinished();
resp.
m_ownAddressWatcher->waitForFinished();
right after the resp. "->cancel()" will perform the cancel sync'd and determine the behavior in this regard.

If you can compile a patch, but not make any sense out of the above, I'll happily attach a set of patches to try.

Btw.: LAN or WAN connection (ie. how much latency?)

Laurent, if you can provide the information requested in comment #11, please add it.

*** Bug 323701 has been marked as a duplicate of this bug. ***

*** Bug 329072 has been marked as a duplicate of this bug. ***

Created attachment 85236 [details]
New crash information added by DrKonqi

kwin (4.11.3) on KDE Platform 4.12.0 using Qt 4.8.2

- What I was doing when the application crashed:

Drag and dropping within the Perforce client running over ssh forwarding from a remote machine.

-- Backtrace (Reduced):
#6  QObject::~QObject (this=0x4219bf0, __in_chrg=<optimized out>) at kernel/qobject.cpp:916
#7  0x00007fa3b6f25fd9 in KWin::Unmanaged::~Unmanaged (this=0x4219bf0, __in_chrg=<optimized out>) at ../../kwin/unmanaged.cpp:46
#8  0x00007fa3b6f263bf in deleteUnmanaged (c=0x4219bf0) at ../../kwin/unmanaged.cpp:114
#9  KWin::Unmanaged::release (this=0x4219bf0, on_shutdown=false) at ../../kwin/unmanaged.cpp:109
#10 0x00007fa3b6edf5ed in unmapNotifyEvent (this=0x4219bf0) at ../../kwin/events.cpp:1512

The crash handler suggested that my crash was related to this bug.   

Application: kwin (4.11.12)
KDE Platform Version: 4.14.2
Qt Version: 4.8.6
Operating System: Linux 3.18.0-rc3-1.ga73bb9e-desktop x86_64
Distribution: "openSUSE 13.2 (Harlequin) (x86_64)"

-- Information about the crash:
- What I was doing when the application crashed:

I am running liferea and hit the 's' key which brings up a popped up search window.
I hit esc to close the window and return the to main window and kwin crashes.

I've done it three times.

kwin-4.11.12

The crash can be reproduced every time.

-- Backtrace:
Application: KWin (kwin), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[KCrash Handler]
#6  0x00007fc4114d2031 in QObject::~QObject() (this=0xfa3cd0, __in_chrg=<optimized out>) at kernel/qobject.cpp:943
#7  0x00007fc4174dded3 in KWin::Unmanaged::~Unmanaged() (this=0xfa3cd0, __in_chrg=<optimized out>) at /usr/src/debug/kde-workspace-4.11.12/kwin/unmanaged.cpp:44
#8  0x00007fc4174dded3 in KWin::Unmanaged::~Unmanaged() (this=0xfa3cd0, __in_chrg=<optimized out>) at /usr/src/debug/kde-workspace-4.11.12/kwin/unmanaged.cpp:46
#9  0x00007fc4174de23d in KWin::Unmanaged::release(bool) (c=0xfa3cd0) at /usr/src/debug/kde-workspace-4.11.12/kwin/unmanaged.cpp:115
#10 0x00007fc4174de23d in KWin::Unmanaged::release(bool) (this=this@entry=0xfa3cd0, on_shutdown=on_shutdown@entry=false) at /usr/src/debug/kde-workspace-4.11.12/kwin/unmanaged.cpp:110
#11 0x00007fc41749c7c3 in KWin::Unmanaged::windowEvent(_XEvent*) (this=0xfa3cd0) at /usr/src/debug/kde-workspace-4.11.12/kwin/events.cpp:1522
#12 0x00007fc41749c7c3 in KWin::Unmanaged::windowEvent(_XEvent*) (this=0xfa3cd0, e=e@entry=0x7fff0b7f46a0) at /usr/src/debug/kde-workspace-4.11.12/kwin/events.cpp:1490
#13 0x00007fc41749da05 in KWin::Workspace::workspaceEvent(_XEvent*) (this=0x10793f0, e=e@entry=0x7fff0b7f46a0) at /usr/src/debug/kde-workspace-4.11.12/kwin/events.cpp:167
#14 0x00007fc4174918f0 in KWin::Application::x11EventFilter(_XEvent*) (this=0x7fff0b7f4a90, e=0x7fff0b7f46a0) at /usr/src/debug/kde-workspace-4.11.12/kwin/main.cpp:422
#15 0x00007fc41069d6fc in qt_x11EventFilter(XEvent*) (ev=0x7fff0b7f46a0) at kernel/qapplication_x11.cpp:436
#16 0x00007fc4106ab1f9 in QApplication::x11ProcessEvent(_XEvent*) (this=0x7fff0b7f4a90, event=event@entry=0x7fff0b7f46a0) at kernel/qapplication_x11.cpp:3365
#17 0x00007fc4106d2f30 in QEventDispatcherX11::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0xe8f100, flags=...) at kernel/qeventdispatcher_x11.cpp:132
#18 0x00007fc4114b7e6f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7fff0b7f4900, flags=...) at kernel/qeventloop.cpp:149
#19 0x00007fc4114b8165 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7fff0b7f4900, flags=...) at kernel/qeventloop.cpp:204
#20 0x00007fc4114bd5b9 in QCoreApplication::exec() () at kernel/qcoreapplication.cpp:1225
#21 0x00007fc410633f3c in QApplication::exec() () at kernel/qapplication.cpp:3823
#22 0x00007fc4174927a3 in kdemain(int, char**) (argc=3, argv=0x7fff0b7f4bd8) at /usr/src/debug/kde-workspace-4.11.12/kwin/main.cpp:597
#23 0x00007fc41708db05 in __libc_start_main (main=0x400730 <main(int, char**)>, argc=3, argv=0x7fff0b7f4bd8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff0b7f4bc8) at libc-start.c:285
#24 0x000000000040075e in _start () at ../sysdeps/x86_64/start.S:122

Possible duplicates by query: bug 327287, bug 323701.

Report to https://bugs.kde.org/

a)  is liferea a remote client?
b) see comment #11 - since you can reproduce this at will, it would be great if you could compile a patched version of KWin to test the theory. Can you?

a) liferea is a rss feed reader
b) I can currently reproduce it.  I suppose if I replace kwin, and restart it, I'll have the same environment.  Let me know what needs to be patched. 

Hopefully I can compile kwin without too many dependencies.

(In reply to Rich Coe from comment #18)
> a) liferea is a rss feed reader
The question is whether it runs remotely, ie. whether client and server are on different machines.

If not or unsure, please provide the outputs of "xprop" and "xwininfo" on the (main) liferea window.

Since the theory is about hostname resolution, which should be skipped for local clients, it can be ruled out if this happens for local clients as well.

No, it does not run remotely.   
It's happening with a local client.

Please provide "xprop" and "xwininfo" outputs for absolute confirmation (the logical condition matters and *may* invalidly be remote for a physically local client)

It's a locally running app.  You could look at it's home page or install it yourself.
In the meantime, I'm in kwin dependency hell.   kwin wants extra-cmake-modules, but when I check out extra-cmake-modules, it wants qt5 (like it's building for frameworks) and not qt4. (sigh).

(In reply to Rich Coe from comment #22)
> It's a locally running app.  You could look at it's home page or install it
> yourself.

You're missing the point.
If the client screws the WM_CLIENT_MACHINE hint, KWin might still "believe" it's remote.
(This can also happen if the hostname changes at runtime due to networkmanager)

=> please dump the props and hints and maybe compare them to those of other clients yourself as well.

> In the meantime, I'm in kwin dependency hell.   kwin wants
> extra-cmake-modules, but when I check out extra-cmake-modules, it wants qt5
> (like it's building for frameworks) and not qt4. (sigh).

That actually is kwin 5 - you need to compile kde-workspace/kwin if you want KWin 4.

Yeah, I had to checkout the right tag for ecm and branch for kwin.  Much better now.
Yes, there was something weird going on where my hostname did get switched and I had
to switch it back.  
xprop -id 0x8c00001
WM_CLASS(STRING) = "liferea", "Liferea"
WM_CLIENT_MACHINE(STRING) = "google.com"

(In reply to Rich Coe from comment #24)
> WM_CLIENT_MACHINE(STRING) = "google.com"

I assume "hostname" will not suggest that you're google.com? ;-)
=> "Remote", actually liferea authors probably do not understand the meaning of that property and set it to whatever rss source they operate on? You should file a bug, this may have other unwanted consequences.

Good thing is that the comment #11 theory is still in contention =)

Please ensure that the self-compiled vanilla version of kwin stil causes the segfault.
I'll then attach a pot. patch to the bug.

Yes can still crash kwin with version compiled from source.

Sorry about that, I didn't do all the libraries.  When I replace all the libraries and kwin, it's working as it should.

you could try to set the build mode to "release" (in your kde-workspace build dir, run "ccmake ." to get an ncurses driven build config UI)

Created attachment 89684 [details]
queud connection patch (a1)

Created attachment 89685 [details]
disconnect patch (a2)

Created attachment 89686 [details]
sync cancel patch (b)

In case and hope you can re-cause the crash, I attached three patches.
The can be applied by
   patch -p2 < __patch_name.diff
from the kde-workspace/kwin directory.

You can apply all at once to check whether any of them has the potential to fix this crash.
If so, please revert them ("git reset --hard HEAD") and try each alone.

I don't think a combination of two would be required, but if, it's likely "b" and one of the "a" patches.

Many thanks for your efforts so far.

I've reproduced it again.  I'll start working on the patches.

I built kwin 3 times, once for each patch.
patch (a1) and patch (a2) definitely fail.   
patch (b) passes.

(In reply to Rich Coe from comment #33)
> patch (b) passes.

Splendid =)
Many thanks again!

FTR: How many times did you challenge the patch?
(Not, that in the end only the caused delay mitigated the bug)

I cycled through each version, native, a1, a2, b at least two times to make sure I didn't have a false positive.  I'm currently running patch b to insure it survives regular usage.

(In reply to Rich Coe from comment #35)
> I'm currently running patch b to insure it survives regular usage.
Ok, sounds "promising" so far - if you don't get the crash within a week, we can assume this to be a confirmation for the patch.

Created attachment 90089 [details]
New crash information added by DrKonqi

kwin (4.11.13) on KDE Platform 4.14.2 using Qt 4.8.6

- What I was doing when the application crashed:

Not exactly sure. Was running gnome-disks over SSH and KWin crashed.

-- Backtrace (Reduced):
#6  0x00007f9cd0898f33 in QObject::~QObject (this=0x2a77e00, __in_chrg=<optimized out>) at kernel/qobject.cpp:911
#7  0x00007f9cd6990f99 in KWin::Deleted::~Deleted (this=this@entry=0x2a77e00, __in_chrg=<optimized out>) at ../../kwin/deleted.cpp:48
#8  0x00007f9cd6991179 in KWin::Deleted::~Deleted (this=0x2a77e00, __in_chrg=<optimized out>) at ../../kwin/deleted.cpp:55
#9  0x00007f9cd0898668 in QObject::event (this=0x2a77e00, e=<optimized out>) at kernel/qobject.cpp:1203
#10 0x00007f9ccfbd329c in QApplicationPrivate::notify_helper (this=this@entry=0x1aaafd0, receiver=receiver@entry=0x2a77e00, e=e@entry=0x276ff20) at kernel/qapplication.cpp:4570

Git commit 38eb2604788b0a2d0c772254cfbba8b484c6270e by Thomas Lübking.
Committed on 01/12/2014 at 22:14.
Pushed by luebking into branch 'master'.

Sync GetAddrInfo thread cancel in destructor

QFutureWatcher::cancel() might be still processed
(it's another thread) while the inherited ~QObject()
deletes the FutureWatcher
REVIEW: 121225

M  +2    -0    client_machine.cpp

http://commits.kde.org/kwin/38eb2604788b0a2d0c772254cfbba8b484c6270e

*** Bug 345181 has been marked as a duplicate of this bug. ***

*** Bug 350227 has been marked as a duplicate of this bug. ***

*** Bug 361352 has been marked as a duplicate of this bug. ***