Application: kwin (4.8.00 (4.8.0) KDE Platform Version: 4.8.00 (4.8.0 Qt Version: 4.8.0 Operating System: Linux 3.2.0-14-generic x86_64 Distribution: Ubuntu precise (development branch) -- Information about the crash: - What I was doing when the application crashed: Tried to log out of an KDE session, as I had difficulties of removing the screen lock. It was activated every few seconds, so I needed to constantly move mouse and/or type something. As energy profiles seem gone in 12.04 (I had a "movies"-preset in 11.10 that fixed this problem), I needed to log out and start a regular session via remote in order to work without interruption. Using nxclient and shadow (previous session) or unix mode (now). The crash message popped up on login, so I don't know if something happened at the login or logout procedure. A login via VNC mode inbetween those was unsuccessful, error message was "Cannot set RFB password" - Unusual behavior I noticed: *custom shortcuts were not accessible since about yesterday *the screen lock issue *taskbar was very slow to access, had to click many times on the battery monitor widget to make it open, and also many times on ->logout until the previous session really ended -- 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 0x7f378c60e7a0 (LWP 4908))] Thread 3 (Thread 0x7f376fb6a700 (LWP 4912)): #0 0x00007f378be414d3 in select () at ../sysdeps/unix/syscall-template.S:82 #1 0x00007f378764a8e6 in qt_safe_select (nfds=18, fdread=0x2741298, fdwrite=0x2741530, fdexcept=0x27417c8, orig_timeout=<optimized out>) at kernel/qcore_unix.cpp:83 #2 0x00007f378764fcf0 in QEventDispatcherUNIXPrivate::doSelect (this=0x27410e0, flags=..., timeout=0x0) at kernel/qeventdispatcher_unix.cpp:223 #3 0x00007f37876501f3 in QEventDispatcherUNIX::processEvents (this=0x27174a0, flags=...) at kernel/qeventdispatcher_unix.cpp:926 #4 0x00007f378761d202 in QEventLoop::processEvents (this=<optimized out>, flags=...) at kernel/qeventloop.cpp:149 #5 0x00007f378761d457 in QEventLoop::exec (this=0x7f376fb69db0, flags=...) at kernel/qeventloop.cpp:204 #6 0x00007f378751cf17 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:501 #7 0x00007f37875fcf9f in QInotifyFileSystemWatcherEngine::run (this=0x2740120) at io/qfilesystemwatcher_inotify.cpp:248 #8 0x00007f378751ff3b in QThreadPrivate::start (arg=0x2740120) at thread/qthread_unix.cpp:298 #9 0x00007f37807c3e2b in start_thread (arg=0x7f376fb6a700) at pthread_create.c:304 #10 0x00007f378be480dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f376f369700 (LWP 4913)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007f378890c1f2 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4 #2 0x00007f378890c229 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4 #3 0x00007f37807c3e2b in start_thread (arg=0x7f376f369700) at pthread_create.c:304 #4 0x00007f378be480dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f378c60e7a0 (LWP 4908)): [KCrash Handler] #6 __GI___libc_free (mem=0x1) at malloc.c:3709 #7 0x00007f378989b769 in XFree (data=<optimized out>) at ../../src/XlibInt.c:1701 #8 0x00007f37894412ee in XRRUpdateConfiguration (event=0x7fffba6a3ef0) at ../../src/Xrandr.c:446 #9 0x00007f378c17268f in KWin::Workspace::workspaceEvent (this=0x25e5850, e=0x7fffba6a3ef0) at ../../kwin/events.cpp:466 #10 0x00007f378c163ee8 in KWin::Application::x11EventFilter (this=0x7fffba6a4200, e=0x7fffba6a3ef0) at ../../kwin/main.cpp:359 #11 0x00007f3786a108d5 in qt_x11EventFilter (ev=0x7fffba6a3ef0) at kernel/qapplication_x11.cpp:440 #12 qt_x11EventFilter (ev=0x7fffba6a3ef0) at kernel/qapplication_x11.cpp:428 #13 0x00007f3786a1fd38 in QApplication::x11ProcessEvent (this=0x7fffba6a4200, event=0x7fffba6a3ef0) at kernel/qapplication_x11.cpp:3441 #14 0x00007f3786a4a11a in QEventDispatcherX11::processEvents (this=0x24a0ad0, flags=...) at kernel/qeventdispatcher_x11.cpp:132 #15 0x00007f378761d202 in QEventLoop::processEvents (this=<optimized out>, flags=...) at kernel/qeventloop.cpp:149 #16 0x00007f378761d457 in QEventLoop::exec (this=0x7fffba6a4140, flags=...) at kernel/qeventloop.cpp:204 #17 0x00007f37876224e7 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1148 #18 0x00007f378c166666 in kdemain (argc=<optimized out>, argv=<optimized out>) at ../../kwin/main.cpp:541 #19 0x00007f378bd8530d in __libc_start_main (main=0x400640 <main(int, char**)>, argc=3, ubp_av=0x7fffba6a4928, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffba6a4918) at libc-start.c:226 #20 0x0000000000400671 in _start () Possible duplicates by query: bug 293209. Reported using DrKonqi
*** This bug has been marked as a duplicate of bug 293209 ***
(In reply to comment #0) > Tried to log out of an KDE session, as I had difficulties of removing the > screen lock. It was activated every few seconds, Raise time? > As energy profiles seem gone in 12.04 (I had a Yesno, I thinkg it shall now be done through activities - see "kcmshell4 powerdevilactivitiesconfig" > *custom shortcuts were not accessible since about yesterday > *the screen lock issue > *taskbar was very slow to access, had to click many times on the battery > monitor widget to make it open, and also many times on ->logout until the > previous session really ended There's probably sth. flooding the X11 event queue - how's the X process CPU load and is sth. else high at cpu load?
(In reply to comment #2) > Raise time? Raise time of what? Screensaver starts after 10 minutes of inactivity and requires a password after 5 seconds. Using the remote connection, the screensaver kicks in after 1-5s. > Yesno, I thinkg it shall now be done through activities - see "kcmshell4 > powerdevilactivitiesconfig" At the moment, there are only Energy Saving Settings + Advanced Settings in the Power Settings Window. However, earlier today there was also "Activity Settings" which is also available via your command. It has three cool tabs: One blank, one called "unnamed3", and one with the nice RTM title "uz6ed". As I didn't spot when one of these settings will be active, I assumed this is just what a box above indicates: Something between an Alpha version and the not-yet-invented greek character before that ;) > There's probably sth. flooding the X11 event queue - how's the X process CPU > load and is sth. else high at cpu load? BOINC is running, total load is somewhere between 2 and 4 (dualcore), @15min it's 2.31. X has 40.5 minutes of CPU time from a total uptime of 28 hours.
(In reply to comment #3) > Raise time of what? Of the screensaver activation ;-) If it however starts every few seconds on remote connections, there might be a config issue - or a bug. (i've no screensavers installed/configured, just use dpms to turn off the screen and explicitly call the locker when i need to lock the terminal) > At the moment, there are only Energy Saving Settings + Advanced Settings in the > Power Settings Window. However, earlier today there was also "Activity > Settings" which is also available via your command. It has three cool tabs: One > blank, one called "unnamed3", and one with the nice RTM title "uz6ed". The refer to the "activities" you can set up eg. via the plasma cashew thing (okey, doesn't look like a stupid cashew anymore ;-) Afaics the profile will change with the activity, so if you setup a "movie" activity (while mediaplayers usually can keep down the screensavers themselves) you should be able to configure a resp. power profile. > BOINC is running, yikes - i recall we had reports regarding this client before. Can you turn it off and check whether this is still an issue? (afair it's more or less closed source and therefore it's not possible to check whether they do funny things - and flooding the X event queue is actually pretty much trivially done by omitting XSync and trigger events as fast as you can)
(In reply to comment #4) > If it however starts every few seconds on remote connections, there might be a > config issue - or a bug. > (i've no screensavers installed/configured, just use dpms to turn off the > screen and explicitly call the locker when i need to lock the terminal) There surely is, but I'm somewhat lazy in filing bugs, none of my (directly affecting) KDE/Ubuntu bugs have ever been resolved. Besides that, as I found a workaround that really worked until last weekend... > Afaics the profile will change with the activity, so if you setup a "movie" > activity (while mediaplayers usually can keep down the screensavers themselves) > you should be able to configure a resp. power profile. Yeah, but what are these activities based on? How do I add a program to the group "movie"? VLC had some troubles fighting the screensaver - that's why I had a profile for that. If that can now be auto-loaded - great. But first I need to setup VLC to be a "movie"-application. > yikes - i recall we had reports regarding this client before. > Can you turn it off and check whether this is still an issue? (afair it's more I just did - 27 seconds between a right-click onto the battery symbol until the menu fired up. And, btw: The clock stopped until the menu was there. So in fact the whole task bar freezes on some actions.
(In reply to comment #5) > Yeah, but what are these activities based on? How do I add a program to the > group "movie"? (not really acquainted with activities, but) you don't - you add an activity and make it run vlc by default. > VLC had some troubles fighting the screensaver Not here btw. There was some bug on this, and the issue was that *something* kept activating dpms, but the reporter didn't figure or report what that was. (ie. even if you explicitly disabled it, it would be re-enabled later on) turn off: "xset -dpms" check state: "xset -q | grep -A5 DPMS" > > Can you turn it off and check whether this is still an issue? (afair it's more > I just did - 27 seconds between a right-click onto the battery symbol until the > menu fired up. And, btw: The clock stopped until the menu was there. So in fact > the whole task bar freezes on some actions. The battery applet will likely do some sync operation when you launch the popup. That operation lasts (27 seconds?? - with a non loaded dualcore?) - the frozen taskbar is a "natural" result. If one does time intense things, one should simply not do so in the main GUI thread, but i guess that timeout is not expected and a result of some deeper issue... None of this is a kwin bug, though. Btw, after turning off the BOIC client (and ensuring no such process remains) did you restart X11 (ie. log out/in at least)?
(In reply to comment #6) > (not really acquainted with activities, but) you don't - you add an activity > and make it run vlc by default. Ah, okay, so if I use five video and three audio players, I need to create 8 profile doing all the same stuff but launching a different program? Genius! > turn off: "xset -dpms" > check state: "xset -q | grep -A5 DPMS" Will check that tomorrow on a remote connection, or is it VLC-specific? On my local account, it disables and enables DPMS just as it should > The battery applet will likely do some sync operation when you launch the > popup. Maybe. But I cannot spot CPU or disk load, it just does nothing until... > That operation lasts (27 seconds?? - with a non loaded dualcore?) - the > frozen taskbar is a "natural" result. Yes, 27 seconds. Now again, but "only" 25 seconds ;) Other symbols do fine and show instant results, or, if they do not, have a delay caused by disk activity. None of them stops the clock... hough. > Btw, after turning off the BOIC client (and ensuring no such process remains) > did you restart X11 (ie. log out/in at least)? No, did you ask for that? ;)
(In reply to comment #7) > Ah, okay, so if I use five video and three audio players, I need to create 8 > profile doing all the same stuff but launching a different program? Genius! The idea would likey be to create one "entertain me!" activity, have a usable power profile, switch to that activity, entertain yourself and leave it afterwards. I guess. > Will check that tomorrow on a remote connection, or is it VLC-specific? On my > local account, it disables and enables DPMS just as it should It might be vlc specific, iirc. that wasn't sorted out. But the report was regarding vlc and the screensaver. (+ a short timeout when dpms became re-enabled) > Maybe. But I cannot spot CPU or disk load, it just does nothing until... Such horrible timeout will rather be some (network?) I/O issue.... (broken HD sectors cause such, but rather not reproducebly on one action...) > No, did you ask for that? ;) Well, if it borked the X11 event queue ... actually not explicitly ;-)
btw, do other windows still update? does the clock update if you suspend the compositor (shift+alt+f12)?
(In reply to comment #8) > It might be vlc specific, iirc. that wasn't sorted out. But the report was > regarding vlc and the screensaver. (+ a short timeout when dpms became > re-enabled) With dpms disabled the problem seems solved. Screen lock after 10 minutes also works, but (local) dimming doesn't. > Such horrible timeout will rather be some (network?) I/O issue.... (broken HD > sectors cause such, but rather not reproducebly on one action...) SMART reports no errors, eth0 is disabled or not connected, wlan0 is up and running. But it's just a battery applet with sharing disabled (never know what sharing my battery status in the local network would be useful for or how to catch that on other machines) > Well, if it borked the X11 event queue ... actually not explicitly ;-) I'll do that later, once some other current tasks are completed. (In reply to comment #9) > btw, do other windows still update? does the clock update if you suspend the > compositor (shift+alt+f12)? Yes, they do, I can even use ALT+TAB to switch around, which should (?) cancel the menu of the battery widget. No, there's no difference exept having ugly window effects and a 3D menu when using ALT+TAB
you should file a bug against the battery applet - i've no idea what could happen before showing that menu. Since the rest of the system isn't blocked, that's no way related to the WM (ie. it's not a visual or even X11 related issue)
Created attachment 68816 [details] New crash information added by DrKonqi kwin (4.8.00 (4.8.0) on KDE Platform 4.8.00 (4.8.0 using Qt 4.8.0 provide more information - done! minimum length reached. same crash as before, maybe some useful stuff in the backtrace... -- Backtrace (Reduced): #6 __GI___libc_free (mem=0x1) at malloc.c:2968 #7 0x00007f99bbe1b769 in XFree (data=<optimized out>) at ../../src/XlibInt.c:1701 #8 0x00007f99bb9c12ee in XRRUpdateConfiguration (event=0x7fffe5bb8610) at ../../src/Xrandr.c:446 #9 0x00007f99be70b6af in KWin::Workspace::workspaceEvent (this=0x1a89f90, e=0x7fffe5bb8610) at ../../kwin/events.cpp:466 #10 0x00007f99be6fcf08 in KWin::Application::x11EventFilter (this=0x7fffe5bb8920, e=0x7fffe5bb8610) at ../../kwin/main.cpp:359
Created attachment 68818 [details] New crash information added by DrKonqi kwin (4.8.00 (4.8.0) on KDE Platform 4.8.00 (4.8.0 using Qt 4.8.0 - What I was doing when the application crashed: changing display resolution in systemsettings, as the default one for this remote session was 1024x600. native resolution is 1440x900 and the current one of the windows machine that is attached is 1600x1200 -> no idea where that netbook resolution came from... changing however didn't work, i'm after the kwin crash still at 1024x600. -- Backtrace (Reduced): #6 __GI___libc_free (mem=0x1) at malloc.c:2968 #7 0x00007f852984f769 in XFree (data=<optimized out>) at ../../src/XlibInt.c:1701 #8 0x00007f85293f52ee in XRRUpdateConfiguration (event=0x7fff2cb1b720) at ../../src/Xrandr.c:446 #9 0x00007f852c13f6af in KWin::Workspace::workspaceEvent (this=0x1a54920, e=0x7fff2cb1b720) at ../../kwin/events.cpp:466 #10 0x00007f852c130f08 in KWin::Application::x11EventFilter (this=0x7fff2cb1ba30, e=0x7fff2cb1b720) at ../../kwin/main.cpp:359
(In reply to comment #13) > changing however didn't work, i'm after the kwin crash still at 1024x600. what kinda supports the idea that this build of libxrandr or one of it's dependencies is broken, yesno? since this is from remote: have to tried to explicitly select the display? xrandr -display :0 -s 1440x900 Is this btw. across vnc or so?
(In reply to comment #14) > what kinda supports the idea that this build of libxrandr or one of it's > dependencies is broken, yesno? Don't know? > since this is from remote: have to tried to explicitly select the display? > xrandr -display :0 -s 1440x900 Has no effect. > Is this btw. across vnc or so? VNC works, but when using it the resolution cannot be changed, and of course it's slow as I have only ~55kb/s upload. This happens when logging in via the Nomachine NX Client, in case of choosing "shadow" (which attaches to the current session) and "unix-kde/gnome/***" (which creates a new one). On logging in via the VNC function of the NX software, everything works as in a regular VNC client, but far smoother. I can see the login procedure and also the taskbar appearing, but then the crash happens and the task bar is gone. And it won't come back, no matter what you do. Restarting after reporting the crash doesn't work, and kwin --replace makes the task bar flash and kwin crash ;) Changing resolution within NX+VNC scales the video output (large resolution in small VNC window), seconds later another crash happens. Playing Quake Live and leaving a game also adjusts the resolution sometimes, today it is at 1024x768, some days before that it did nothing wrong, and before that it was 800x600. And btw, ssh works fine... *G*
The taskbar is plasma desktop - it would align to resolution changes as well. So no wonder it crashes as well. > And btw, ssh works fine... *G* Even in parallel to the running NX session?
(In reply to comment #16) > > And btw, ssh works fine... *G* > Even in parallel to the running NX session? I think so, yes. Attaching to the host (WLAN IP) within a Windows VM works, and having a ssh connection to itself at the same time via my dyndns account is no problem. I might try that tomorrow again (both connections via dyndns on physical different machines), but I can't think of any reason why that should fail. So yes, it works. And two parallel ssh connections are also doing fine.