Summary: | plasma and associated plasmoids freeze | ||
---|---|---|---|
Product: | [Unmaintained] plasma4 | Reporter: | doc.evans |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | andresbajotierra, aseigo, kay.abendroth, lpoujoulat, massimo, mstu, riccardo, StormByte |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
doc.evans
2008-11-13 23:37:36 UTC
This happened again overnight. The only additional information I have is that this time I noticed that clicking on the KDE Menu brought up just a black box instead of the actual menu. Clicking on all other panel items seemed to work as usual (including lancelot). Just happened again. This time clicking on the KDE menu had no effect at all. It's hard to be more specific about what's going on, other than that all the plasmoids are simply not updating themselves visually. But it sure seems to be happening a lot. Please tell me what else you need that might help with this one. It's getting annoying to have to log out just because of this (normally [i.e., in KDE3] I stay logged in for weeks at a time) The most obvious plasmoids that are frozen are the news ticker and the clock on which I have seconds displayed, but as far as I can tell every single one of them is stuck. Since I assume that every plasmoid is run in its own thread (I sure hope so; one wouldn't want to have something like a network communication problem in one plasmoid affect all of them), this seems to indicate that whatever logical entity is responsible for receiving the visual updates is not actually passing them to the screen. As before, everything non-plasma-related is working perfectly. This happened again overnight. I'm seriously considering reverting to KDE3. I sometimes run jobs that take days to complete; having to log out every day or so because the plasmoids all freeze isn't really a tenable option for me (most of the plasmoids aren't that important, but the ones in the panel are; it's pretty inconvenient to try to function if those aren't working properly). That's a weird bug, really weird, wouldn't know what to say. does plasma give you any debug? what if you run 'kquitapp plasma; sleep 2; plasma' without logging out? There are no messages or anything to indicate the problem. Is there some particular logfile that might be useful for me to post? I'll try running the command you suggest next time it happens, and post the result here. I bet that it will work (although of course it's hardly the same as figuring out what's happening and stopping it from occurring). In the past superkaramba used to do this sort of thing all the time, because its architecture was that a network failure in a single theme would affect all themes, because they all ran in the same thread. I can't believe (at least, I hope I can't believe) that plasma has the same design flaw (which would be much more serious in plasma, because so many things, even clocks, are implemented as plasmoids in KDE4 -- having everything stop just because one plasmoid couldn't get data from the network would obviously be a Very Bad Thing). Anyway, I'll post here what happens next time. I don't suppose I'll have to wait for very long. run that in a konsole, and it will print any debug messages. ~/.xsession-errors should contain the same thing but it is much more cluttered (contains any application debug) posting plasma-appletsrc and plasmarc should be of some help too (in $KDEHOME/share/config/) that command simply restarts plasma. can you also post some other information about the system? so the symptoms are: * things are not repainting * things are still interative (pager, etc) this implies that: * plasma is still running and not blocked (otherwise clicking on the pager wouldn't work, right?) * for whatever reason repaints simply aren't happening so my question is: * what version of Qt are you using? * what widgets do you have running (please list all of them)? * what graphics card or chipset and x.org driver are you using? as for issues of design and trying deduce the problems, please don't. just give us descriptions of the information such that we may do a diagnosis utilizing our insight into the code. i find that user diagnostics based on best-guessing, even when done by people who are knowledgeable about software, often results in useful information being accidently overlooked. =) * what version of Qt are you using? How do I find that out? I'm running current 64-bit Kubuntu. Does 4.4.3 make sense? That seems to be the number associated with the installed packages. * what widgets do you have running (please list all of them)? Numbers in parentheses below are the number of instantiations of each plasmoid. Two panels. Application launcher (1). Dictionary (1) Digital Clock (2) Lancelot launcher (1) New Device Notifier (1) News ticker (1) Notes (1) Pager (1) Picture Frame (1) popcheck (1) -- but this was not running when I first reported the bug Show Desktop (1) System Monitor (1) System Tray (1) Task Manager (1) Trashcan (1) Weather Widget (2) I have now removed one panel and the news ticker (since the news ticker in 4.1.3 is not very useful); we'll see if that makes a difference. * what graphics card or chipset and x.org driver are you using? HIS Radeon HD4670 IceQ card. xorg 7.4 I'm sorry about the extraneous noise. I'm used to other projects; I'll try to remember to confine myself to objective statements here. > I have now removed one panel and the news ticker (since the news ticker in
> 4.1.3 is not very useful); we'll see if that makes a difference.
Removing the panel and the news ticker seems to have "fixed" things.
I'll bring the panel back, but not populate it with the news ticker and see what happens over the next few days. That should determine whether the cause of this bug is the second panel or the news ticker.
So I've been experimenting for the past couple of weeks. Here's what seems to be true: 1. As long as there is a single panel, everything seems to be fine. 2. Creating a second panel but leaving it empty, everything seems to be fine. 3. Adding a widget (to the second panel) that performs updates (I used the System Monitor plasmoid) seems to cause occasional short-lived freezes of all plasmoids (specifically including clocks in the first panel). These freezes lasted a few seconds, and seem to occur at random, but generally once per hour or two. 4. Populating the second panel with the news ticker causes th behaviour I originally reported. 3. Adding a widget (to the second panel) that performs updates (I used the System Monitor plasmoid) seems to cause occasional short-lived freezes of all plasmoids (specifically including clocks in the first panel). These freezes lasted a few seconds, and seem to occur at random, but generally once per hour or two. ok, so these freezes will be *specific* to widgets and what they are doing. the widgets do not run out-of-process, though most widgets do the bulk of their hard work either out of process or in threads. for the system monitor, that would imply that it's polling something (or getting poked to update something) that occasionally takes quite a while to do. what things was the system monitor plasmoid monitoring? 4. Populating the second panel with the news ticker causes th behaviour I originally reported. the news ticker has been removed from the releases do to various problems with it and since it's been replaced by the more "plasma" News and RSS Now plasmoids. so that's not a problem anymore. (In reply to comment #11) > > what things was the system monitor plasmoid monitoring? > CPU, RAM, Swap. FWIW, there doesn't seem to be any way to change what is monitored (or what machine is monitored, for that matter; hence bug report http://bugs.kde.org/show_bug.cgi?id=172312). > the news ticker has been removed from the releases do to various problems with > it and since it's been replaced by the more "plasma" News and RSS Now > plasmoids. so that's not a problem anymore. > Right. I just wanted to be thorough in my report. As I stated in KDE mailing list (subject: plasma extremelly unstable), I can confirm this issue, even worse, plasma stops updating its plasmoids, and after some arbitrary time, plasma resets itself (and since then, it is working a bit more of time until it freezes again). I tested with System Monitor - {CPU,TEMP and NETWORK} (the 3 together). Without any plasmoid, it is OK, it only fail when one have loaded certain plasmoids. One may think it is a plasmoid problem, but it freezes all, no only that plasmoid, so maybe is something broken in plasma's core. It seems there are more people having this issues, I found a link to my thread on kde mailing list [1] which could be of use to devs. For more info, see: [1] http://lists.kde.org/?l=kde&m=123428593300431&w=2 I updated to KDE 4.2 over the weekend. This bug still seems to be present. I came in this morning and saw that plasma stopped updating the screen last night at 20:52. As before, everything else seemed to be working; and in particular I could switch desktops by clicking on the pager plasmoid, but no plasmoids were issuing screen updates (including, FWIW, an old superkaramba theme). The plasmoids that were running were: 1. popcheck (superkaramba theme) 2. K menu 3. quicklaunch 4. pager 5. task manager 6. system tray 7. CPU monitor 8. network monitor 9. two clocks 10. device notifier plasmoid #1 was on the desktop; all the others were in the panel. One thing of whose relevance I have no idea: I noticed that the little "i" thingy in the system tray was present at the time of the freeze. *** Bug 185441 has been marked as a duplicate of this bug. *** to summarize, plasma is continuing to work just fine ... but it stops painting updates. this could be a bug in either plasma, Qt or the x.org driver. could the other people on this report other than Doc Evans (since he's already provided this information) share what version of Qt and what video card/driver they are using? looking for some commonalities and/or differences. thanks. Here: Qt - 4.4.2 nvidia-drivers 180.29 Sid/amd64: Qt 4.4.3, Xorg 1.4.2. Nvidia propietary driver, version 177.something . Yeah, all widgets just stop repainting. It happens first time today, I'm testing 4.2 for a week. BTW, all window management like 'show windows on all desktop at once' and 'show all windows on current desktop' stops working too. Alt-tab still works, but I'm using simple KDE3-style alt-tab window switching. I have not checked desktop widgets. This just happened again, but it affected only the plasmoids in the panel. Plasmoids on the desktop are updating OK (this time, anyway). In response to comment #20: the "show on all desktops" is still working (this time). amd64, 4.4.3, fresh installled Nvidia 180.35 drivers. It happens again, but it's slightly different: - Expose, windows switching, etc (ctrl+F8) works fine - Black rectangle does not appear when clicking on K. Nothing happens at all. - dashboard (ctrl+F12) does not appear - it happens after monitor was resumed after stand by (but 'after' does bnot mean 'beacause of') PS How to log out correctly if (when) plasma dies again? And another hint, or possibly a red herring (in other words: I'm about to describe a bug, but I'm not certain that it's the same one): Since updating to KDE 4.2, I am seeing many *short* freezes, where all the plasmoids stop updating for perhaps ten seconds or so. This happens several times a day. I have a bunch of CPU and network activity plasmoids, and several clocks, and it seems like (just my impression) that the more of those I have, the more frequently these short freezes occur. Looking back over the reports (even just my own), they don't seem to be hugely consistent. But I know that, at least for my own part, each report was an accurate report of behaviour I experienced. I have no idea whether the developers suspect a race condition, but just in case they do it might be worth mentioning that my CPU has four cores, which would tend to exacerbate a race condition if one exists. I don't think I mentioned: amd64 installation on an Intel chip here. IN reply to comment #23: this seems another bug. I had this issues too and were/are caused by faulty nvidia-drivers (maybe ATI has the same problems as well I don't know) It happens again. More info: - Whet it happens, Alt+Tab starts working like kde3 (no effects), but 10-20 seconds later, it becomes normal again. Expose works fine. - Desktop is completely dead: no reaction on left/right click on any widget / empty space. - It happens all the time when I works for three hours. Quite annoying. 4.4.3, NVidia 180.35, Amd64, kde 4.2 from debian experimental. nVidia driver version 180.35 is known to be VERY buggie and it causes a lot of freezes. Please update to 180.37. Also, can anyone try with Qt4.5 ? Thanks (In reply to comment #26) > nVidia driver version 180.35 is known to be VERY buggie and it causes a lot of > freezes. Please update to 180.37. I was the initial reporter for this bug, and I'm not using nvidia. FYI, I've had two freezes in the past 24 hours :-( One thing I don't think I've mentioned is that I have all desktop effects disabled. Does anyone have network partitions defined at Fstab, (and also mounted) ? Do you lost the connection when Plasma freezes ? (or are that partitions still accesible after it?) I got a similar freeze. when I lost the connection with a Samba partition mounted over the network. I attached a GDB to Plasma and I got that the Device Notifier widget(and Solid) was trying to access that "dead" partition so It got locked and Plasma stopped redrawing itself. Maybe out situations could be similar. Thanks 4.2.0 and qt 4.4 frezes quite often, but kde 4.2.1 and qt 4.5 work fine for now. The same NVidia driver. It is not nvidia-related, I believe. (In reply to comment #28) > Does anyone have network partitions defined at Fstab, (and also mounted) ? Do > you lost the connection when Plasma freezes ? (or are that partitions still > accesible after it?) I have a bunch of filesystems mounted over the network. I will make an explicit check next time I get a freeze (I'm sure I won't have to wait long :-( I experience a freeze every day or two) but I am pretty sure that the only thing that is affected when the freeze occurs is plasma. Everything else that I tried seemed to work fine, and I think I would have noticed if the network-mounted filesystems weren't accessible. > > I got a similar freeze. when I lost the connection with a Samba partition > mounted over the network. I attached a GDB to Plasma and I got that the Device > Notifier widget(and Solid) was trying to access that "dead" partition so It got > locked and Plasma stopped redrawing itself. It would be really bad if a single rogue/malfunctioning/buggy plasmoid could bring the whole desktop to a halt. I would hope that that can't happen. My desktop froze at 05:30 this morning (according to the clock on it when I came in this morning). I checked, and all the network-mounted filesystems were accessible. The only thing that seemed to be non-functional was plasma. Mh: may be we can get some extra information attaching a debugger to Plasma to see where it's freezing. Please, do the following when Plasma hangs the next time: - Open Konsole (Alt+F2 to start KRunner to launch Konsole) - Type "pidof plasma" and get the ID of the Plasma process - Type "gdb --pid PIDNUMBER" where PIDNUMBER is the ID of Plasma you got of the last command GDB will start and load some information ( you can type "set logging on" on GDB to log all the output to a "gdb.txt" file ) - When GDB finished loading the information type "bt full" and press Return a couple of times until there is no more information (trace) left. Then paste that information here. That trace should says us where it's locking. Thanks for all your efforts and patience :) Here you go. Not much here: ---- #0 0x00007fb509e48236 in poll () from /lib/libc.so.6 No symbol table info available. #1 0x00007fb50614b3c8 in ?? () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #2 0x00007fb50614b6eb in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #3 0x00007fb50aa0417e in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 No symbol table info available. #4 0x00007fb50b191a6f in ?? () from /usr/lib/libQtGui.so.4 No symbol table info available. #5 0x00007fb50a9da682 in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 No symbol table info available. #6 0x00007fb50a9da80d in QEventLoop::exec () from /usr/lib/libQtCore.so.4 No symbol table info available. #7 0x00007fb50a9dccbd in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 No symbol table info available. #8 0x00007fb50effcd6b in kdemain (argc=1, argv=0x7fff1745e408) at /build/buildd/kdebase-workspace-4.2.0/plasma/shells/desktop/main.cpp:54 aboutData = {d = 0x8bffa0} app = (class PlasmaApp *) 0x8ed580 rc = <value optimized out> #9 0x00007fb509d89466 in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #10 0x00000000004007c9 in _start () No locals. #0 0x00007fb509e48236 in poll () from /lib/libc.so.6 No symbol table info available. #1 0x00007fb50614b3c8 in ?? () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #2 0x00007fb50614b6eb in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #3 0x00007fb50aa0417e in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 No symbol table info available. #4 0x00007fb50b191a6f in ?? () from /usr/lib/libQtGui.so.4 No symbol table info available. #5 0x00007fb50a9da682 in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 No symbol table info available. #6 0x00007fb50a9da80d in QEventLoop::exec () from /usr/lib/libQtCore.so.4 No symbol table info available. #7 0x00007fb50a9dccbd in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 No symbol table info available. #8 0x00007fb50effcd6b in kdemain (argc=1, argv=0x7fff1745e408) at /build/buildd/kdebase-workspace-4.2.0/plasma/shells/desktop/main.cpp:54 aboutData = {d = 0x8bffa0} app = (class PlasmaApp *) 0x8ed580 rc = <value optimized out> #9 0x00007fb509d89466 in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #10 0x00000000004007c9 in _start () No locals. Undefined command: "exit". Try "help". The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /usr/bin/plasma, process 20930 And another one: ---- #0 0x00007f01a898d236 in poll () from /lib/libc.so.6 No symbol table info available. #1 0x00007f01a4c903c8 in ?? () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #2 0x00007f01a4c906eb in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #3 0x00007f01a954915f in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 No symbol table info available. #4 0x00007f01a9cd6a6f in ?? () from /usr/lib/libQtGui.so.4 No symbol table info available. #5 0x00007f01a951f682 in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 No symbol table info available. #6 0x00007f01a951f80d in QEventLoop::exec () from /usr/lib/libQtCore.so.4 No symbol table info available. #7 0x00007f01a9521cbd in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 No symbol table info available. #8 0x00007f01adb41d6b in kdemain (argc=1, argv=0x7fffb5fa3948) at /build/buildd/kdebase-workspace-4.2.0/plasma/shells/desktop/main.cpp:54 aboutData = {d = 0x2459fa0} app = (class PlasmaApp *) 0x2487580 rc = <value optimized out> #9 0x00007f01a88ce466 in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #10 0x00000000004007c9 in _start () No locals. #0 0x00007f01a898d236 in poll () from /lib/libc.so.6 No symbol table info available. #1 0x00007f01a4c903c8 in ?? () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #2 0x00007f01a4c906eb in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #3 0x00007f01a954915f in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 No symbol table info available. #4 0x00007f01a9cd6a6f in ?? () from /usr/lib/libQtGui.so.4 No symbol table info available. #5 0x00007f01a951f682 in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 No symbol table info available. #6 0x00007f01a951f80d in QEventLoop::exec () from /usr/lib/libQtCore.so.4 No symbol table info available. #7 0x00007f01a9521cbd in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 No symbol table info available. #8 0x00007f01adb41d6b in kdemain (argc=1, argv=0x7fffb5fa3948) at /build/buildd/kdebase-workspace-4.2.0/plasma/shells/desktop/main.cpp:54 aboutData = {d = 0x2459fa0} app = (class PlasmaApp *) 0x2487580 rc = <value optimized out> #9 0x00007f01a88ce466 in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #10 0x00000000004007c9 in _start () No locals. Strange. It looks like it's inside its normal event loop (no freeze) I can assure you that it was frozen both times :-( The symptoms seem to differ slightly from freeze to freeze. On the most recent occasion, I recall that: the clocks were stopped; clicking on the K-menu icon wouldn't do anything; there was no pager visible (odd, that; usually it's still visible); closing a task (e.g., FF) did not cause any visible change to the task manager in the panel; the two monitor plasmoids (network and CPU) were not changing. Aha! Progress at inducing this bug! This procedure seems to have a pretty high probability of making this bug occur: 1. Copy a CD containing a very large number of individual files to a directory on the hard drive (so this will take a long time; half an hour or more) 2. The notification will pop up for a while and then go away. 3. Click the "i" icon to keep the notification window on the screen. It seems that often a freeze will occur before the CD has finished copying. (I've had three plasma freezes in the past hour, all while copying a CD with a large number of files and keeping the notification popup on the screen.) I was just experimenting with QT 4.5 and KDE 4.2.1, and I found something that maybe usefull: with KDE compiled with QT 4.5, plasma will not freeze, instead of frezing, it will go in a stage of bad draws (windows in taskbar with no names, and other weird things in repainting), so I assume the problem is definitely at repainting stage I have a very similar problem, maybe with the same root cause. At random, plasma freezes with same symptoms. After some (apparently random) time, it unfreezes. I have two instances of the frame widget, choosing images (about three thousands), from a remote Samba server. When the signal quality (WiFi..) is lower, freezes are more frequent. Using Latencytop it reports high latencies on CIFS related functions. Maybe the taskbar should run in its own thread, so bad WiFi signal quality (a problem for picture frames,ok,but it's not a KDE problem) doesn't interfere with the taskbar? (yes, that's a KDE problem!) Sorry for the double post- I forgot to add system specs: Gentoo x86_64, kernel 2.6.28 vanilla, KDE 4.2.2 with Qt 4.5 With KDE 4.2.1 (compiled with Qt 4.4 and then recompiled with Qt 4.5) the problem wasn't so bothering, I can't be sure that it was really present. Yes, the problem is MUCH less annoying with QT 4.5 than with QT 4.4 despite it is still present. (In reply to comment #39) > I have a very similar problem, maybe with the same root cause. > At random, plasma freezes with same symptoms. After some (apparently random) > time, it unfreezes. I have never seen an unfreeze. On another matter: what does it take for this to be marked something other than UNCONFIRMED? @doc.evans@gmail.com: the bug can be marked as NEW when someone else can reliably reproduce the bug and provide steps to reproduce or testcase files. Changing the bug status will not change everything if the developers don't know how to reproduce and therefore, how to try to fix it. BTW: I'm going to look at the steps you provided on comment 37 (sorry for not looking at them before..) Thanks for the patience BTW: have you tried the same steps on comment 37 but excluding the CD ? (just copying a large quantity of files from/to different folders on the same HD) Thanks I did some tests: Using: Qt: 4.5.1 (qt-copy 958974) KDE: 4.2.71 (KDE 4.2.71 (KDE 4.3 >= 20090428)) kdelibs svn rev. 960693 / kdebase svn rev. 960693 on ArchLinux i686 - Kernel 2.6.29.1 Copying 165files in 88directories (4.0Gb~) from a DVD to my HD didn't caused a freeze Copying 10000files (50b each) from HD to HD (different folders) didn't caused a freeze. This could be fixed on trunk, or we are missing some other factor in the equation. (most probably), or this freeze is related to some special configuration in your system. I just tried to copy a 3.6GB directory hierarchy within my /tmp partition. Plasma froze after 150MB had been transferred. probably pretty simple to explain: the "freeze" is not a freeze at all, it's just not painting. why? pixmap exhaustion due to the pixmap leaks. why was it doing it during big file transfers? the progress bar _used_ to cache itself over and over again, which probably led to the issue being triggered even faster. these issues are resolved in upcoming qt and kde releases. |