Application: kwin_x11 (5.1.1) Qt Version: 5.4.0 Operating System: Linux 3.16.6-2-desktop x86_64 Distribution: "openSUSE 13.2 (Harlequin) (x86_64)" -- Information about the crash: - What I was doing when the application crashed: I set OpenGL interface to EGL and when I pressed Apply it crashed. -- Backtrace: Application: KWin (kwin_x11), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f8c90b87800 (LWP 4945))] Thread 6 (Thread 0x7f8c76a35700 (LWP 4955)): #0 0x00007f8c9065aa63 in select () at /lib64/libc.so.6 #1 0x00007f8c8e77a239 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () at /usr/lib64/libQt5Core.so.5 #2 0x00007f8c8e77bbb5 in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*) () at /usr/lib64/libQt5Core.so.5 #3 0x00007f8c8e77bffb in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #4 0x00007f8c8e724a6b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #5 0x00007f8c8e5479fa in QThread::exec() () at /usr/lib64/libQt5Core.so.5 #6 0x00007f8c87dc4128 in () at /usr/lib64/libQt5Qml.so.5 #7 0x00007f8c8e54c61f in () at /usr/lib64/libQt5Core.so.5 #8 0x00007f8c86fab0a4 in start_thread () at /lib64/libpthread.so.0 #9 0x00007f8c906617fd in clone () at /lib64/libc.so.6 Thread 5 (Thread 0x7f8c74dfd700 (LWP 4973)): #0 0x00007f8c9065aa63 in select () at /lib64/libc.so.6 #1 0x00007f8c8e77a239 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () at /usr/lib64/libQt5Core.so.5 #2 0x00007f8c8e77bbb5 in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*) () at /usr/lib64/libQt5Core.so.5 #3 0x00007f8c8e77bffb in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #4 0x00007f8c8e724a6b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #5 0x00007f8c8e5479fa in QThread::exec() () at /usr/lib64/libQt5Core.so.5 #6 0x00007f8c87dc4128 in () at /usr/lib64/libQt5Qml.so.5 #7 0x00007f8c8e54c61f in () at /usr/lib64/libQt5Core.so.5 #8 0x00007f8c86fab0a4 in start_thread () at /lib64/libpthread.so.0 #9 0x00007f8c906617fd in clone () at /lib64/libc.so.6 Thread 4 (Thread 0x7f8c7055d700 (LWP 4980)): #0 0x00007f8c9065a397 in ioctl () at /lib64/libc.so.6 #1 0x00007f8c90bd18c9 in uki_firegl_MicroSleep () at /usr/lib64/libatiuki.so.1 #2 0x00007f8c733fda70 in () at /usr/lib64/dri/fglrx_dri.so #3 0x00007f8c72766992 in () at /usr/lib64/dri/fglrx_dri.so #4 0x00007f8c727669e5 in () at /usr/lib64/dri/fglrx_dri.so #5 0x00007f8c86fab0a4 in start_thread () at /lib64/libpthread.so.0 #6 0x00007f8c906617fd in clone () at /lib64/libc.so.6 Thread 3 (Thread 0x7f8c6e9be700 (LWP 4984)): #0 0x00007f8c86faf05f in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x00007f8c8cad361b in () at /usr/lib64/libQt5Script.so.5 #2 0x00007f8c8cad3649 in () at /usr/lib64/libQt5Script.so.5 #3 0x00007f8c86fab0a4 in start_thread () at /lib64/libpthread.so.0 #4 0x00007f8c906617fd in clone () at /lib64/libc.so.6 Thread 2 (Thread 0x7f8beaf64700 (LWP 5504)): #0 0x00007f8c86faf05f in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x00007f8c8e54d63b in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib64/libQt5Core.so.5 #2 0x00007f8c8cf52abb in () at /usr/lib64/libQt5Quick.so.5 #3 0x00007f8c8cf52f53 in () at /usr/lib64/libQt5Quick.so.5 #4 0x00007f8c8e54c61f in () at /usr/lib64/libQt5Core.so.5 #5 0x00007f8c86fab0a4 in start_thread () at /lib64/libpthread.so.0 #6 0x00007f8c906617fd in clone () at /lib64/libc.so.6 Thread 1 (Thread 0x7f8c90b87800 (LWP 4945)): [KCrash Handler] #5 0x00007f8be3eb2fb0 in () at /usr/lib64/libEGL.so.1 #6 0x00007f8be3eaba90 in eglCreateContext () at /usr/lib64/libEGL.so.1 #7 0x00007f8c902d87a0 in () at /usr/lib64/libkwin.so.5 #8 0x00007f8c902d8836 in () at /usr/lib64/libkwin.so.5 #9 0x00007f8c902d916f in () at /usr/lib64/libkwin.so.5 #10 0x00007f8c9026cd45 in () at /usr/lib64/libkwin.so.5 #11 0x00007f8c9024fdef in () at /usr/lib64/libkwin.so.5 #12 0x00007f8c9025058a in () at /usr/lib64/libkwin.so.5 #13 0x00007f8c90251178 in () at /usr/lib64/libkwin.so.5 #14 0x00007f8c902ef135 in () at /usr/lib64/libkwin.so.5 #15 0x00007f8c902f6be3 in () at /usr/lib64/libkwin.so.5 #16 0x00007f8c8d3db69f in () at /usr/lib64/libQt5DBus.so.5 #17 0x00007f8c8e757166 in QObject::event(QEvent*) () at /usr/lib64/libQt5Core.so.5 #18 0x00007f8c8f3e41dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #19 0x00007f8c8f3e91f0 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #20 0x00007f8c8e726b05 in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5 #21 0x00007f8c8e72899f in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQt5Core.so.5 #22 0x00007f8c8e77bf84 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #23 0x00007f8c7bb02b0d in () at /usr/lib64/qt5/plugins/platforms/libqxcb.so #24 0x00007f8c8e724a6b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #25 0x00007f8c8e72c0d6 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 #26 0x00007f8c90928bb3 in kdemain () at /usr/lib64/libkdeinit5_kwin_x11.so #27 0x00007f8c9059db05 in __libc_start_main () at /lib64/libc.so.6 #28 0x000000000040088e in _start () Reported using DrKonqi
crashes in "eglCreateContext()" - do you attempt to use OpenGL 3.1? Try GL 2.0 instead and also please post the outout of "es2_info" It's however a driver bug.
Hello, Yes I have set it to OpenGL 3.1 I changed it to OpenGL 2.0 but I cannot find any application called es2_info. By the way, I use the proprietary driver of amd. On Tuesday 02 of December 2014 21:53:20 you wrote: > https://bugs.kde.org/show_bug.cgi?id=341506 > > Thomas Lübking <thomas.luebking@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |UPSTREAM > Status|UNCONFIRMED |RESOLVED > Component|general |scene-opengl > > --- Comment #1 from Thomas Lübking <thomas.luebking@gmail.com> --- > crashes in "eglCreateContext()" - do you attempt to use OpenGL 3.1? > Try GL 2.0 instead and also please post the outout of "es2_info" > > It's however a driver bug.
Does it work with GL 2.0? es2_info is in the mesa-demos package, which may collide w/ fglrx (but i mostly wanted to know which gpu/driver and whether EGL works at all w/o crashing)
Created attachment 89823 [details] attachment-30998-0.html Hello, it crashed again, using GL 2.0. Actually, I left my pc @home open while I am in my office and I sshed there and saw that the kded5 is using too much memory -which actually is increasing, too. Is there any memory leak? Before 3 hours it was about 400M and now it is 694M, according the htop tool. On Wed, Dec 3, 2014 at 12:32 AM, Thomas Lübking <thomas.luebking@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=341506 > > Thomas Lübking <thomas.luebking@gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Flags| |Catalyst+ > > --- Comment #3 from Thomas Lübking <thomas.luebking@gmail.com> --- > Does it work with GL 2.0? > > es2_info is in the mesa-demos package, which may collide w/ fglrx (but i > mostly > wanted to know which gpu/driver and whether EGL works at all w/o crashing) > > -- > You are receiving this mail because: > You reported the bug. >
(In reply to pmanousis from comment #4) > Hello, it crashed again, using GL 2.0. With the very same backtrace? > Actually, I left my pc @home open while I am in my office and I sshed there > and saw that the kded5 is using too much memory -which actually is > increasing, too. Is there any memory leak? Maybe, however: a) this is not related to kwin. A memory leak in kded would be in one of the daemons. You'd have to ideally isolate which one ("kcmshell5 kded" allows to toggle them) b) Increased memory usage does not necessarily imply a leak (ie. "lost" memory) c) "htop" is really no good reference to track memory usage (neither is top) - however notice that the relevant (ie. getting you a remote idea) field is "RES", "VIRT" includes shared memory as well as files mapped into the process memory (ie. also the file cache - the value is close to meaningless) To track whether your entire system increases memory usage, run grep MemAvailable /proc/meminfo If there's actually unusual memory usage in one process, a tool like "massif" (valgrind tool) or (brnad new ;-) "heaptrack"[1] allows to check why. [1] http://milianw.de/tag/heaptrack