Version: (using KDE 4.2.90) Compiler: gcc 4.3.3 Gentoo 4.3.3-r2 p1.2, pie-10.1.5 OS: Linux Installed from: Gentoo Packages When Plasma is spammed with hundreds of windows (i.e. bug #197367), it will soon stop to respond (ps aux lists it as "T" - stopped). All windows created afterwards will have black contents with a transparent border (looking very much like Windows Aero). I assume it even crashed and the window I am (not) seeing is the KDE Crash Handler, which halted the plasma process (thus the T state). I am using non-forced compositing effects. (Availability check is enabled.) Assumed reason: Graphics card went out of texture ids or memory, and Plasma does not notice. Ideas for fix: * Check number of available textures / free texture memory. * Check GL return values for errors. * Disable compositing if anything odd happens.
ps aux lists: /usr/lib64/kde4/libexec/drkonqi -display :0.0 --appname plasma-desktop --kdeinit --signal 11 --pid 10164 --appversion 0.3 --programname Plasma-Arbeitsfläche --bugaddress submit@bugs.kde.org --startupid 0 and kdeinit4: plasma-desktop [kdeinit] So I assume it was indeed a crash.
There was some X Pixmaps leaks causing Plasma to stop updating itself and hanging. This leaks were fixed when using Qt4.5.1 and after beta2 (IIRC) Indeed, it seems DrKonqi was launch, I wonder why couldn't you see it.. may be there was some other problem with the windows manager? (transparent border?)
(In reply to comment #2) > There was some X Pixmaps leaks causing Plasma to stop updating itself and > hanging. This leaks were fixed when using Qt4.5.1 and after beta2 (IIRC) I am using Qt 4.5.1, and KDE 4.2.91, which was released slightly after 4.3_beta2. I assume those leaks you mentioned are not pure memleaks on the main memory? I am asking, because I would assume that is highly unlikely for such thing to cause any hangs, given the amount of RAM built into this machine, and the amount of swap space available. What seemed odd though is that Plasma never seemed to notice that it is not able to create any new textures. (+info: Even my video card's cooling started when the window spam happened. I assume caused by the all the rendering that suddenly happened.) > Indeed, it seems DrKonqi was launch, I wonder why couldn't you see it. > may be there was some other problem with the windows manager? > (transparent border?) I could see a window with black contents and a transparent border. The size roughly matched my memories of DrKonqi, and ps listed it, so I just assumed that this window might be drkonqi. The guess with texture memory results from experience back in the history of compositing, where it could happen that you got black windows when your video card ran out of memory or had other issues creating the requested textures in the correct format and dimensions.
if this affects all subsequent windows, as noted in comment #1, then it's a kwin issue. if you can get a backtrace on the plasma side of this, then we can do something about it. otherwise this is primarily of interest to kwin at this point.
I had no situation where it happened again (the Akonadi bug appeared just once), and I am not sure I can or want to reproduce it so soon, as it was not easy to get my system back without destroying it (KDE seems very sensitive towards hard reboots and other disk failures). If you have the time, try spawning a few hundred or thousand windows and see what happens. When they flooded the taskbar for a while (till the entries get so thin that they are overlapping in dozens and are no longer clickable), I expect Plasma to crash, and KWin to hang with out-of-textures.
probably not much we can do. We had a pixmap leak in Oxygen windeco which would fasten up the problem. I have never really run out of textures and wouldn't know how to trigger it and in I don't know what to do about it. To me this is kind of not even worth to investigate, so a wontfix. Any comments on that?
Bugs in other applications may trigger this behaviour, which makes it hard to workaround those bugs (i.e. by closing the offending application). Since you can detect when you run out of texture memory, maybe you can just disable compositing in that case?
glGetError() == GL_OUT_OF_MEMORY BUT: i don't know whether this will work as expected (as textures are usually just swapped to RAM.) i've no idea when swapping occurs compared to this condition, but i assume you'll have to spam you entire RAM w/ Textures until you get the error? (and the RAM will swap to disk as well...?!) i however wonder why the availibility checks didn't autosuspend compositing - given that your spammed windows exceeded the GPU TRAM and the rather inferior RAM perfomance :-\
I would expect that the performance in a situation like described in this bug report becomes so bad that compositing is suspended. Instead of checking for GL_OUT_OF_MEMORY which is basically too late, could we watch the number of pixmaps used by kwin in our compositing checks? And if number get's too high, suspend compositing.
the driving question is "what is too high?" KWin isn't the only kid on the block and even if it was, i don't know wether there's a std way to query the available /texture/ ram on the GC (that's not the same as the entire VRAM) - in doubt the user would have to select some size :-\ (also we would want to guess the combined (compressed...) texture size rather than the number.) one /could/ make use of glAreTexturesResident - though that would probably lead to false positives (but i do /not/ know) :-( best solution: do not bloat your memory with nonsense =D
Is it maybe possible to make KWin notice when one application starts to spam windows which reduces the system speed? The window spam seems to be a recurring issue (see bug #222595), so preventing the system from becomming unusable to the point of a hard-reset seems like a valuable goal.
if you did not "disable functionality checks" kwin should suspend compositing whenever the fps go down. However if there are /thousands/ of windows (as mentioned in the bugreport...) they'll drain away the entire available memory X uses for pixmaps (Qts backbuffer) - what is then beyond the WM. Compositing makes everything worse, but at this stage it doesn't really matter anymore. What could _theoretically_ be done is to cap the maximum amount of mapped windows, schedule the other mapping requests (in a loooong queue ;-) and release them everytime a slot gets freed. i'm not sure whether this is an acceptable behaviour for a WM, though :-\ (to kwin it always the plasma client requesting the maps, whether a useless message or the applauncher) However, the core problems here are: a) akonadi yelling thousand warnings in a row (did never happen here, though - i occasionally get one or two) b) the notifcation plasmoid showing messages w/o sense. Other than kwin the plasmoid should have a rough idea about the window content and if it gets thousands of requests from one client it could (much more efficiently) schedule them internally, rather than just spamming your screen I think this is why the central notification system exists: prevent random dialogs from spamming you
yes, I think that could make sense. The question are: * how to detect that a process spamms the desktop * how to interact with the user when it happens For the first one we have to find a really good heuristic to neither cause false positives nor negatives. And the second one might be tricky as well. What should be done? Just close all windows - probably not. Kill the offending process - probably not. Ask the user - might be tricky when the system is already barely usebale any more. Nevertheless I think this would be a nice addition to kwin's feature to kill hanging processes.
(In reply to comment #12) > if you did not "disable functionality checks" kwin should suspend compositing > whenever the fps go down. I forgot to mention: While my desktop can handle the few hundreds of error messages akonadi spams, my netbook is apparently not able to do that, even with compositing completely/manually disabled. It bails out at about 50, when it gets really slow. If you leave it on for a while (instead of hard resetting), you can see the number of windows growing into the hundreds, though very slowly.
If an application is spamming hundreds of windows then it's an application bug. It's not the WM's job to fix an application bug.
(In reply to comment #15) > If an application is spamming hundreds of windows then it's an application bug. > It's not the WM's job to fix an application bug. I fully agree with what you said here! However, what I not agree with is the implication you are making. IMO it is very well the WM's job to not produce an unusable system because one application is buggy.
(In reply to comment #16) > IMO it is very well the WM's job to not produce an unusable system because one > application is buggy. The WM is NOT producing anything here. The map request would just be honored on a non managed window system. Try to open an xterm, kill kwin and call "while 1; do xterm & done" ;-) (for more fun pass it as execute parameter as well =) The question is whether to make the WM intercept these requests and sythetically deny what otherwise would be granted, not based upon some protocol, but "because it knows better".
Issue persists in KDE 4.4.1.
I do not see what KWin could do about it. It is not the job of the WM to fix the clients, sorry. And as Thomas pointed out in comment #17 it would not be the fix in the proper place as even without a WM the system would go down. This might as well be a dup of bug #192470
*** Bug 253869 has been marked as a duplicate of this bug. ***