Bug 257850 - KWin hangs from time to time, no keyboard input possible, GL_OUT_OF_MEMORY
Summary: KWin hangs from time to time, no keyboard input possible, GL_OUT_OF_MEMORY
Status: REPORTED
Alias: None
Product: kwin
Classification: Plasma
Component: scene-opengl (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-25 08:25 UTC by Jan Rauberg
Modified: 2023-03-27 09:32 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Rauberg 2010-11-25 08:25:34 UTC
Version:           unspecified (using KDE 4.5.3) 
OS:                Linux

From time to time (once per day) KWin hangs. No keyboard input is possible. I have to kill kwin from console. After that it is possible to use the xterm to start a new session of kwin. So I can work further without rebooting the whole system. When it hangs again, I get some messages in the XTerm from where I have started kwin.

kwin(16836) KWin::checkGLError: GL error ( PostPaint ):  "GL_OUT_OF_MEMORY" 
kwin(16836): Can't enable invalid render target! 

I have to do the same procedure again and again, because I'm using a 24/7 machine. This is very annoying. This behavior was new since KDE 4.5.1 on Ubuntu 10.10. I'm using a NVIDIA GeForce 7600GS.

Reproducible: Sometimes

Steps to Reproduce:
Don't know how.

Actual Results:  
kwin(16836) KWin::checkGLError: GL error ( PostPaint ):  "GL_OUT_OF_MEMORY" 
kwin(16836): Can't enable invalid render target!
Comment 1 Thomas Lübking 2010-11-25 23:08:03 UTC
nice, a texture leak... :-(

it's probably sufficient to suspend/resume compositing in this case (shift+alt+f12)

- do you have the blur effect enabled?
- do you blacklist the lanczos filter?

- (wild one) check your GPU temp (the GS is probably passive?), overheating memory can cause this "at random"
Comment 2 Jan Rauberg 2010-11-26 08:10:32 UTC
- No blur effect, even if I enable it. My windows are transparent during moving, but nothing gets blured in the background even with enabled blur effect.
- Where is the lanczos filter?

- My GPU temperature is at 75°C and yes, it is passively cooled. But I think the temp is ok for a passive GPU.

Next time I will try the shift+alt+F12 trick. I hope the keys are working...
(In reply to comment #1)
> nice, a texture leak... :-(
> 
> it's probably sufficient to suspend/resume compositing in this case
> (shift+alt+f12)
> 
> - do you have the blur effect enabled?
> - do you blacklist the lanczos filter?
> 
> - (wild one) check your GPU temp (the GS is probably passive?), overheating
> memory can cause this "at random"
Comment 3 Thomas Lübking 2010-11-26 16:51:12 UTC
(In reply to comment #2)
> - No blur effect, even if I enable it.
ok, unless we don't know what this is - don't ;-)

> My windows are transparent during moving
those are not affected anyway. clients have to mar blurred regions, supported by (many) plasma-desktop widgets/panels the ARGB features of the Bespin/Oxygen/QtCurve UI styles.

> - Where is the lanczos filter?
for 4.5 you have to blacklist it to not use it for sure,
append the output of 
echo "NVIDIA=`glxinfo | grep 'OpenGL renderer string' | sed -e 's/^.*: //'`:-:`glxinfo | grep 'OpenGL version string' | sed -e 's/^.*: //'`"

to the [Blacklist][Lanczos] section in ~/.kde/share/config/kwinrc

Semi-OT:
> - My GPU temperature is at 75°C and yes, it is passively cooled. But I think
> the temp is ok for a passive GPU.

It's probably not causing this, but not exactly "low" either (i use a passive 7600GT @ 45°C)
While your GPU can stand this temperature for some time (the colder, the older ;-) it can cause trouble in the rest of your system, because your memory & esp. HDD can NOT live at this temperature for a long time (in case of the HDD: minutes ;-) and your CPU won't like it too much either.
You should keep an eye on the general system temperature and consider improving the general box cooling (-> chassis fan)
Comment 4 Thomas Lübking 2010-11-26 18:35:51 UTC
just for the records:
crossing the mesa code, GL_OUT_OF_MEMORY is thrown unconditionally whenever the driver fails to provide a new framebuffer, for what reason ever.
Comment 5 Martin Flöser 2010-11-26 18:59:37 UTC
though it's the NVIDIA driver... Nevertheless we could add a check in 
GLRenderTarget
Comment 6 Martin Flöser 2012-04-09 08:13:49 UTC
Changing to wishlist to add support for handling GL_OUT_OF_MEMORY. Possible solution would be to disable compositing when running into such a situation, though I don't know how we actually could test such an issue :-)