Summary: | KWin crashes upon every startup - can't drag windows, no window borders/functions (close, minimise, maximise etc), taskbar not functioning properly. | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | John Smith <mr.williambux> |
Component: | activities | Assignee: | Cédric Bellegarde <web> |
Status: | RESOLVED DUPLICATE | ||
Severity: | grave | CC: | cfeck, kwin-bugs-null |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Mageia RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
John Smith
2014-05-04 14:23:32 UTC
the symptoms are usual for an unmanaged workspace, but what's important (and missing) is a backtrace (the "details" part) - we don't even know what version this is - let alone where it crashes. (In reply to comment #1) > the symptoms are usual for an unmanaged workspace, but what's important (and > missing) is a backtrace (the "details" part) - we don't even know what > version this is - let alone where it crashes. I think that it is KDE4, and KWin just crashes upon EVERY startup. Well, KDE4 has now seen ~60 different versions and what we need is the backtrace, the "developer details" in the crash dialog. Otherwise we could only recognize the report and then ignore it. KWin does for sure not crash here at all. The reason could be an ABI break by your distro, a broken library, a broken driver, some exotic configuration, .... and a dozen more reasons. And to get an idea about that, we need the backtrace of the crash - that's why it's dumped in the crash dialog. (In reply to comment #3) > Well, KDE4 has now seen ~60 different versions and what we need is the > backtrace, the "developer details" in the crash dialog. > Otherwise we could only recognize the report and then ignore it. > > KWin does for sure not crash here at all. > > The reason could be an ABI break by your distro, a broken library, a broken > driver, some exotic configuration, .... and a dozen more reasons. > > And to get an idea about that, we need the backtrace of the crash - that's > why it's dumped in the crash dialog. Sorry for inconvinience, here is the backtrace: Application: KWin (kwin), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7fe0122bf740 (LWP 3185))] Thread 2 (Thread 0x7fe00b9db700 (LWP 3195)): #0 0x00000032f30ebbf9 in syscall () from /lib64/libc.so.6 #1 0x00000030b387a0e4 in ?? () from /lib64/libQtCore.so.4 #2 0x00000030b38762d5 in QMutex::lockInternal() () from /lib64/libQtCore.so.4 #3 0x0000003ec0a09aac in KActivities::Consumer::listActivities() const () from /lib64/libkactivities.so.6 #4 0x0000003868c407d4 in ?? () from /lib64/libkdeinit4_kwin.so #5 0x0000003868c4baa3 in ?? () from /lib64/libkdeinit4_kwin.so #6 0x0000003868c4fe06 in ?? () from /lib64/libkdeinit4_kwin.so #7 0x00000030b386f26d in ?? () from /lib64/libQtCore.so.4 #8 0x00000030b387b63c in ?? () from /lib64/libQtCore.so.4 #9 0x00000032f3407d18 in start_thread () from /lib64/libpthread.so.0 #10 0x00000032f30f043d in clone () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () Thread 1 (Thread 0x7fe0122bf740 (LWP 3185)): [KCrash Handler] #5 0x0000003868c53277 in ?? () from /lib64/libkdeinit4_kwin.so #6 0x0000003868c81aed in ?? () from /lib64/libkdeinit4_kwin.so #7 0x0000003868c456c4 in ?? () from /lib64/libkdeinit4_kwin.so #8 0x0000003868c49be7 in ?? () from /lib64/libkdeinit4_kwin.so #9 0x0000003868c4ae51 in ?? () from /lib64/libkdeinit4_kwin.so #10 0x0000003868c65c30 in ?? () from /lib64/libkdeinit4_kwin.so #11 0x0000003868c6782e in kdemain () from /lib64/libkdeinit4_kwin.so #12 0x00000032f3021ba5 in __libc_start_main () from /lib64/libc.so.6 #13 0x0000000000400751 in _start () No problem - just required the info ;-) kactivitymanagerd is - likely - responding slow (or not at all) what drives us into a Qt bug (threaded dbus access) An infinite re-crash however seems like a real problem with qdbus or kactivitymanagerd. You could install another WM (eg. openbox) and will be asked to use that instead what gives you a usable session (you can activate windows etc.) and then try to access kactivitymanagerd qdbus org.kde.kactivitymanagerd or see whether it's running at all ps ax | grep kactivitymanagerd *** This bug has been marked as a duplicate of bug 315453 *** Can we decide it is bug 315453 without seeing debug symbols? There, it is always the secondary thread that crashes. To bet my right arm? No. To bet your right arm? Yes ;-) The presence of the threaded activity dbus call and the lock (and the bunch of F20 dupes that encountered lately) just make it "very likely" (which thread holds the lock would have impressed me if threading was any deterministic...) @John If you can, please install kdebase4-workspace-debuginfo (and qt4-debuginfo) and provide a more speaking backtrace of the crash. Btw: do you use either the binary nvidia or fglrx (catalyst; amd/ati) driver? |