After a weekend away, kscreenlocker_greet allows me to type my password, but will not accept the correct password. switching to a console terminal, I notice the process is taking 41% of the systme memory, which is about 4.92 GiB. When I kill the kscreenlocker_greet process, another is spawned. This new kcscreenlocker_greet process accepts the password and I am able to log in. Reproducible: Always Steps to Reproduce: 1. Leave for several days 2. Try to log in 3. Actual Results: Unable to log in Expected Results: Password accepted, process taking very little memory The first time this happened, I changed my password, thinking that something had happened. I would like to troubleshoot this more, but not sure how to proceed. This has happened for three weeks now, and the process is still running when I come back in to work. Is there a way to run ksceenlocker_greet on valgrind or something?
you can run the actual binary of kscreenlocker_greet with --testing through gdb or valgrind. Though there is a chance that the actual problem won't be hit when in test mode.
I can confirm this bug. It's still appear with kscreenlocker versions 5.8.3 - 5.8.5. Memory leak amount is ~ 250mB per hour. In testing mode it produce: *** QOpenGLShader::link: error: program lacks a fragment shader shader compilation failed: "error: program lacks a fragment shader\n" QOpenGLShader::link: error: program lacks a fragment shader QOpenGLShader::compile(Fragment): 0:6(2): error: No precision specified in this scope for type `vec4' 0:7(2): error: No precision specified in this scope for type `float' 0:8(2): error: No precision specified in this scope for type `float' 0:9(2): error: No precision specified in this scope for type `float' 0:9(22): error: initializer of global variable `outerRadius' must be a constant expression 0:10(2): error: No precision specified in this scope for type `vec4' 0:13(2): error: No precision specified in this scope for type `vec4' 0:15(2): error: No precision specified in this scope for type `vec2' 0:16(2): error: No precision specified in this scope for type `float' *** Problematic Fragment shader source code *** #ifndef GL_FRAGMENT_PRECISION_HIGH #define highp mediump #endif #line 1 varying highp vec2 qt_TexCoord0; uniform highp float qt_Opacity; uniform lowp sampler2D source; uniform vec4 colorBorder; float blend = 0.01; float innerRadius = 0.47; float outerRadius = innerRadius + 0.02; vec4 colorEmpty = vec4(0.0, 0.0, 0.0, 0.0); void main() { vec4 colorSource = texture2D(source, qt_TexCoord0.st); vec2 m = qt_TexCoord0 - vec2(0.5, 0.5); float dist = sqrt(m.x * m.x + m.y * m.y); if (dist < innerRadius) gl_FragColor = colorSource; else if (dist < innerRadius + blend) gl_FragColor = mix(colorSource, colorBorder, ((dist - innerRadius) / blend)); else if (dist < outerRadius) gl_FragColor = colorBorder; else if (dist < outerRadius + blend) gl_FragColor = mix(colorBorder, colorEmpty, ((dist - outerRadius) / blend)); else gl_FragColor = colorEmpty ; gl_FragColor = gl_FragColor * qt_Opacity; } ***
Created attachment 103490 [details] valgrind kscreen log for 1 minute Attaching valgrind log
Are you using an OpenGL es build of Qt?
(In reply to Martin Gräßlin from comment #4) > Are you using an OpenGL es build of Qt? 98% sure that answer is yes. I can check check it tomorrow. I saw bug somewhere around regarding qt + gles and "error: program lacks a fragment shader", but it seems that there were no information about memory leaks.
> 98% sure that answer is yes. If it is: switch to normal OpenGL (in case you are a Gentoo user this requires a full(!) rebuild of everything of Qt and everything depending on Qt). OpenGL ES is not (!) intended to be used on normal desktop systems. The memory leak you are experience might be a side effect of the broken OpenGL setup.
And yes, the valgrind log shows you are using OpenGL ES and it's full of errors due to that.
(In reply to Martin Gräßlin from comment #6) > > 98% sure that answer is yes. > > If it is: switch to normal OpenGL (in case you are a Gentoo user this > requires a full(!) rebuild of everything of Qt and everything depending on > Qt). OpenGL ES is not (!) intended to be used on normal desktop systems. The > memory leak you are experience might be a side effect of the broken OpenGL > setup. Thanks, I'll try. But I'm not sure that it will be ok, because sometimes I test wayland and other DEs which require gles. And as far as I remember on some packages emerge requires choosing one of opengl or gles.
By the way kscreenlocker is only program (installed on my computer) that causing such memory leak.
> wayland and other DEs which require gles. Wayland does not (!) require GLES.
(In reply to Martin Gräßlin from comment #10) > > wayland and other DEs which require gles. > > Wayland does not (!) require GLES. Wayland by itself not require gles. But other DEs require gles to run (compile) with wayland support.
Am 18. Januar 2017 22:43:31 MEZ schrieb bugzilla_noreply@kde.org: >https://bugs.kde.org/show_bug.cgi?id=363749 > >--- Comment #11 from s@zxc.pp.ua --- >(In reply to Martin Gräßlin from comment #10) >> > wayland and other DEs which require gles. >> >> Wayland does not (!) require GLES. > >Wayland by itself not require gles. But other DEs require gles to run >(compile) >with wayland support. No, is an old Linux myth. Just think about it, that wouldn't work anywhere, no distro compiles with gles. This problem only exists for Gentoo users.
(In reply to Martin Gräßlin from comment #12) > No, is an old Linux myth. Just think about it, that wouldn't work anywhere, > no distro compiles with gles. > > This problem only exists for Gentoo users. It's not true :). dev-libs/efl: configure: error: Full OpenGL with EGL is not supported, please add --with-opengl=es to your configure options to switch to EGL + OpenGL ES.
Created attachment 103532 [details] attachment-21126-0.html We don't need to discuss this The problem that users have incorrectly Gles is always gentoo. Guess why I immediately jumped to the conclusion that you use Gentoo. Gles an gl are not mutual exclusive in the system. But in Qt they are.
Can this issue safely be closed?
Yes, that shader is fixed for GLES. But OPs setup is also being weird for no reason. Though it's weird that stderr allegedly causes memory to go up. That shouldn't happen.