See: https://bugzilla.redhat.com/show_bug.cgi?id=1014466 Versions: kde-workspace-4.11.2-1.fc19.x86_64 libreoffice-core-4.1.2.2-1.fc19.x86_64 Problem: When I open LibreOffice calc (not so sure about writer), kwin intermittently crashes. This has been going on for quite a while, perhaps more than a month. I cannot say exactly when it started, somewhere around kde-4.10 or kde-4.11, likely the former. Reproducible: Sometimes Here is the debug info from drkonqi: Application: KWin (kwin), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) [Current thread is 1 (Thread 0x7fd3d50868c0 (LWP 6076))] Thread 2 (Thread 0x7fd3c61af700 (LWP 6080)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000003e51b860bb in QTWTF::TCMalloc_PageHeap::scavengerThread (this=0x3e51e83f00 <QTWTF::pageheap_memory>) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:2359 #2 0x0000003e51b860f9 in QTWTF::TCMalloc_PageHeap::runScavengerThread (context=<optimized out>) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:1464 #3 0x0000003e2f807c53 in start_thread (arg=0x7fd3c61af700) at pthread_create.c:308 #4 0x0000003e2f0f5e1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 1 (Thread 0x7fd3d50868c0 (LWP 6076)): [KCrash Handler] #6 0x0000003769ceac24 in KWin::effectWindow (w=0x7fd3b80019b0) at /usr/src/debug/kde-workspace-4.11.2/kwin/effects.cpp:1778 #7 0x0000003769cc9114 in KWin::Scene::paintScreen (this=this@entry=0xcbfe80, mask=mask@entry=0x7fffd5525eec, region=region@entry=0x7fffd5525fa0) at /usr/src/debug/kde-workspace-4.11.2/kwin/scene.cpp:143 #8 0x0000003769cdb877 in KWin::SceneOpenGL::paint (this=0xcbfe80, damage=..., toplevels=...) at /usr/src/debug/kde-workspace-4.11.2/kwin/scene_opengl.cpp:360 #9 0x0000003769cc1093 in KWin::Compositor::performCompositing (this=0x84a930) at /usr/src/debug/kde-workspace-4.11.2/kwin/composite.cpp:618 #10 0x0000003e3b592141 in QObject::event (this=0x84a930, e=<optimized out>) at kernel/qobject.cpp:1156 #11 0x0000003e3f5c84dc in QApplicationPrivate::notify_helper (this=this@entry=0x6c8740, receiver=receiver@entry=0x84a930, e=e@entry=0x7fffd5526390) at kernel/qapplication.cpp:4562 #12 0x0000003e3f5ceaa0 in QApplication::notify (this=this@entry=0x7fffd5526860, receiver=receiver@entry=0x84a930, e=e@entry=0x7fffd5526390) at kernel/qapplication.cpp:4348 #13 0x0000003762a3fe9a in KApplication::notify (this=0x7fffd5526860, receiver=0x84a930, event=0x7fffd5526390) at /usr/src/debug/kdelibs-4.11.2/kdeui/kernel/kapplication.cpp:311 #14 0x0000003e3b57a26d in QCoreApplication::notifyInternal (this=0x7fffd5526860, receiver=0x84a930, event=0x7fffd5526390) at kernel/qcoreapplication.cpp:949 #15 0x0000003e3b5a9c13 in sendEvent (event=<optimized out>, receiver=<optimized out>) at kernel/qcoreapplication.h:231 #16 QTimerInfoList::activateTimers (this=0x6c9138) at kernel/qeventdispatcher_unix.cpp:621 #17 0x0000003e3b5a9c90 in QEventDispatcherUNIX::activateTimers (this=this@entry=0x669c80) at kernel/qeventdispatcher_unix.cpp:878 #18 0x0000003e3b5aa600 in QEventDispatcherUNIX::processEvents (this=this@entry=0x669c80, flags=...) at kernel/qeventdispatcher_unix.cpp:940 #19 0x0000003e3f6658e6 in QEventDispatcherX11::processEvents (this=0x669c80, flags=...) at kernel/qeventdispatcher_x11.cpp:152 #20 0x0000003e3b578ecf in QEventLoop::processEvents (this=this@entry=0x7fffd55266d0, flags=...) at kernel/qeventloop.cpp:149 #21 0x0000003e3b5791c5 in QEventLoop::exec (this=this@entry=0x7fffd55266d0, flags=...) at kernel/qeventloop.cpp:204 #22 0x0000003e3b57e45b in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1221 #23 0x0000003e3f5c6c9c in QApplication::exec () at kernel/qapplication.cpp:3823 #24 0x0000003769c7b806 in kdemain (argc=3, argv=0x7fffd55269a8) at /usr/src/debug/kde-workspace-4.11.2/kwin/main.cpp:597Application: KWin (kwin), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) [Current thread is 1 (Thread 0x7fd3d50868c0 (LWP 6076))] Thread 2 (Thread 0x7fd3c61af700 (LWP 6080)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x0000003e51b860bb in QTWTF::TCMalloc_PageHeap::scavengerThread (this=0x3e51e83f00 <QTWTF::pageheap_memory>) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:2359 #2 0x0000003e51b860f9 in QTWTF::TCMalloc_PageHeap::runScavengerThread (context=<optimized out>) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:1464 #3 0x0000003e2f807c53 in start_thread (arg=0x7fd3c61af700) at pthread_create.c:308 #4 0x0000003e2f0f5e1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 1 (Thread 0x7fd3d50868c0 (LWP 6076)): [KCrash Handler] #6 0x0000003769ceac24 in KWin::effectWindow (w=0x7fd3b80019b0) at /usr/src/debug/kde-workspace-4.11.2/kwin/effects.cpp:1778 #7 0x0000003769cc9114 in KWin::Scene::paintScreen (this=this@entry=0xcbfe80, mask=mask@entry=0x7fffd5525eec, region=region@entry=0x7fffd5525fa0) at /usr/src/debug/kde-workspace-4.11.2/kwin/scene.cpp:143 #8 0x0000003769cdb877 in KWin::SceneOpenGL::paint (this=0xcbfe80, damage=..., toplevels=...) at /usr/src/debug/kde-workspace-4.11.2/kwin/scene_opengl.cpp:360 #9 0x0000003769cc1093 in KWin::Compositor::performCompositing (this=0x84a930) at /usr/src/debug/kde-workspace-4.11.2/kwin/composite.cpp:618 #10 0x0000003e3b592141 in QObject::event (this=0x84a930, e=<optimized out>) at kernel/qobject.cpp:1156 #11 0x0000003e3f5c84dc in QApplicationPrivate::notify_helper (this=this@entry=0x6c8740, receiver=receiver@entry=0x84a930, e=e@entry=0x7fffd5526390) at kernel/qapplication.cpp:4562 #12 0x0000003e3f5ceaa0 in QApplication::notify (this=this@entry=0x7fffd5526860, receiver=receiver@entry=0x84a930, e=e@entry=0x7fffd5526390) at kernel/qapplication.cpp:4348 #13 0x0000003762a3fe9a in KApplication::notify (this=0x7fffd5526860, receiver=0x84a930, event=0x7fffd5526390) at /usr/src/debug/kdelibs-4.11.2/kdeui/kernel/kapplication.cpp:311 #14 0x0000003e3b57a26d in QCoreApplication::notifyInternal (this=0x7fffd5526860, receiver=0x84a930, event=0x7fffd5526390) at kernel/qcoreapplication.cpp:949 #15 0x0000003e3b5a9c13 in sendEvent (event=<optimized out>, receiver=<optimized out>) at kernel/qcoreapplication.h:231 #16 QTimerInfoList::activateTimers (this=0x6c9138) at kernel/qeventdispatcher_unix.cpp:621 #17 0x0000003e3b5a9c90 in QEventDispatcherUNIX::activateTimers (this=this@entry=0x669c80) at kernel/qeventdispatcher_unix.cpp:878 #18 0x0000003e3b5aa600 in QEventDispatcherUNIX::processEvents (this=this@entry=0x669c80, flags=...) at kernel/qeventdispatcher_unix.cpp:940 #19 0x0000003e3f6658e6 in QEventDispatcherX11::processEvents (this=0x669c80, flags=...) at kernel/qeventdispatcher_x11.cpp:152 #20 0x0000003e3b578ecf in QEventLoop::processEvents (this=this@entry=0x7fffd55266d0, flags=...) at kernel/qeventloop.cpp:149 #21 0x0000003e3b5791c5 in QEventLoop::exec (this=this@entry=0x7fffd55266d0, flags=...) at kernel/qeventloop.cpp:204 #22 0x0000003e3b57e45b in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1221 #23 0x0000003e3f5c6c9c in QApplication::exec () at kernel/qapplication.cpp:3823 #24 0x0000003769c7b806 in kdemain (argc=3, argv=0x7fffd55269a8) at /usr/src/debug/kde-workspace-4.11.2/kwin/main.cpp:597 #25 0x0000003e2f021b75 in __libc_start_main (main=0x4009d0 <main(int, char**)>, argc=3, ubp_av=0x7fffd55269a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffd5526998) at libc-start.c:274 #26 0x0000000000400a01 in _start () #25 0x0000003e2f021b75 in __libc_start_main (main=0x4009d0 <main(int, char**)>, argc=3, ubp_av=0x7fffd55269a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffd5526998) at libc-start.c:274 #26 0x0000000000400a01 in _start ()
This has been going on since 4.10 or 4.11.1, more likely the former... a while, anyway.
Either a deleted Deleted makes it into Scene::stacking_order or stacking_order is corrupted during painting or a window gets deleted during painting. - Do all backtraces look the same? * in KWin::effectWindow (w=...) at /usr/src/debug/kde-workspace-4.11.2/kwin/effects.cpp:1778 * in KWin::Scene::paintScreen (this=..., mask=..., region=...) at /usr/src/debug/kde-workspace-4.11.2/kwin/scene.cpp:143 * in KWin::SceneOpenGL::paint (this=..., damage=..., toplevels=...) at /usr/src/debug/kde-workspace-4.11.2/kwin/scene_opengl.cpp:360 - please provide the output of "qdbus org.kde.kwin /KWin supportInformation" - I assume the crash happens with the disappearing LOCalc splash screen?
I'll provide a new backtrace, the next time it occurs. The program window fully appears and then, suddenly, kwin crashes, leaving the application window without a frame, hence no maximize, close buttons, titlebar, etc. Sometimes, when I have been working on the spreadsheet and I want to sort the columns, the sort window appears and then kwin crashes.
Created attachment 82643 [details] Output of qdbus... Libreoffice was not running when I generated this output. There was no crash. Am I supposed to run this during a crash scenario, or is this ok? Also, Rex Dieter told me that I was not using the preferred qt graphics system. I was using native, but have changed it to raster last night. I notice that the performance of the desktop is much snappier, smoother. There have been no crashes with the raster graphics system yet, but I just got up and only just turned on the computer 20 minutes ago.
The supportInformation are fine - they just reflect some hardware detection and kwin settings and won't change during the crash scenario (also when kwin crashed, you cannot query it for informations ;-) LibreOffice has an option to use hardware acceleration, ie. OpenGL. Since intel has issues with several GL contexts at a time (though usually not in this contxt), it might be worth a shot trying to disable that in LO (extras/options/view) in case the issue remains. The graphicssystem *may* have impact in case this actually is a memory corruption from the driver. Otherwise it should not.
(In reply to comment #5) > LibreOffice has an option to use hardware acceleration, ie. OpenGL. > Since intel has issues with several GL contexts at a time (though usually > not in this contxt), it might be worth a shot trying to disable that in LO > (extras/options/view) in case the issue remains. I haven't done that yet, since I haven't had a crash lately. > The graphicssystem *may* have impact in case this actually is a memory > corruption from the driver. Otherwise it should not. That must be it, then. Since I changed from native to raster, I have not experienced one single crash. Also, the mouse, which was so jerky and even sometimes made the pages reverse scroll direction for a few lines, before continuing properly, and the slow and unsteady desktop... all of these things are gone! I think it is a corrupted driver, just as you said.
Let's mark as upstream then to indicate a driver but. Raster is the better option anyway and native is gone in the current development version.
I just happened again, and, as I have indicated, I am using raster, not qt native. It occured, likely as you had indicated, just as the splash sreen disappeared and the main window appeared. Unfortunately, out of habit, I clicked away the drkonqi screen before realizing that I want to run it. How do I start drkonqi manually to get the backtrace?
> How do I start drkonqi manually to get the > backtrace? I think it's gone now. You will have to wait till it crashes again.
Created attachment 82792 [details] Kwin crash output Kwin crashed again, using the raster method (as I now always use, as per default). I was editing a libreoffice odt spreadsheet and wanted to insert some text from a text file into a column of the spreadsheet. The insert window appeared and at that instant, kwin crashed.
I notice that the bug status is marked as 'resolved', but it is clearly NOT resolved, as we see. Shouldn't it be changed to reflect the actual state of affairs?
Well, afaics Martin changed the state according to your suggestion :-P This is not a memory corruption, though. There's some dangeling pointer / nullptr deref here. I just blame Scene::Window / EffectWindow mapping in scene_opengl.cpp because I see a lot of QHash::operator[] abuse there - which is just protected by asserts... @Peter, I assume your version is compiled NDEBUG? Can you compile a debug enabled or patched version?
I can certainly provide either debug-enabled or patched builds for testing purposes
In particular, what cmake_build_type is preferable for testing purposes here? Is RelWithDebInfo sufficient, or Debug?
I used to regularly compile programs from tarballs, but I haven't done it for years, since everything I want is nowadays in the fedora repos. Still, I insist on only using properly made rpms, such as Rex seems to be offering to prepare :-)
According to my /usr/share/apps/cmake/modules/FindKDE4Internal.cmake, only CMAKE_CXX_FLAGS_DEBUG doesn't set NDEBUG, sorry. @Martin How do you think about a patch that deals with the QHash::operator[] in the only possbile way - for 4.11, i mean?
> How do you think about a patch that deals with the QHash::operator[] in the > only possbile way - for 4.11, i mean? as long as it won't conflict, it's fine with me. I think I had some changes around the Scene::Window creation in a branch - see https://git.reviewboard.kde.org/r/111207
(In reply to comment #17) > https://git.reviewboard.kde.org/r/111207 That would conflict but is afaics not in master. Or did you mean to alter it in this regard (while that should raise odds to create a merge conflict)?
> That would conflict but is afaics not in master. correct, but I want to force me to merge my Wayland-related branches in ;-) But I expect that I won't get to it this week again as I should also pick up some KWindowSystem work again and had the stupid idea today to port khotkeys to Qt5... > Or did you mean to alter it in this regard (while that should raise odds to > create a merge conflict)? No, I hadn't thought of that
*** Bug 326820 has been marked as a duplicate of this bug. ***
Also see bug #327103
@Martin To deal with this (aside QHash worries) and esp. bug #327103 (where we'd have to check for the availability of effectWindow()) and in general, it seems to make sense to move "QHash< Toplevel*, Window* > windows" from scene_*.h to scene.h/protected, unify the virtual public Q_SLOTS (they're always the same) and then check effectWindow() to be valid. For this purpose, m_scene/setScene should become a common protected member of Window as well .... iow, should https://git.reviewboard.kde.org/r/111207/ maybe happen in 4.11 and master and then create a common QHash::op[] abuse fix on top of that?
> iow, should https://git.reviewboard.kde.org/r/111207/ maybe happen in 4.11 > and master and then create a common QHash::op[] abuse fix on top of that? I'm going to merge the review request either today or next week. It's on my todo list for the first week of work. I'm not sure whether I'll get to it today given that I'm just fighting building frameworks ;-) I'm unsure whether it's 4.11 material, I'll think about it
(In reply to comment #23) > I'm unsure whether it's 4.11 material, I'll think about it as it ended only in master, I decided against 4.11
Old NOTABUG due to bad setting.
OOC: What "Bad setting"?
I had had the graphics system set to native, but it should have been raster. Oh, I see that in my comment #12, I was still haivng crashes after correcting the setting. However, this has been working fine for months, so with all of the new KDE releases and librooffice releases every couple of weeks, the p[roblem has no longer materialized for soo long that I cannot even remember when I last experienced it.
Ok, feel free to re-open if it re-appears.