Bug 2078

Moving the lock dialog around or moving any other windows around?  Not sure how you could do the latter outside of multiple sessions, but need to ask...

Thanks!

Moving ANY windows around. When Trinity session starts, it always launches "kdesktop_lock --internal [PID of kdesktop]".

OK, so you're seeing this when the kdesktop_lock process is sleeping.  I'll look into it.

Are you using compton or kompmgr, or running with no compositor enabled?

I cannot reproduce this on my nVidia test system, but I don't use any compositor.

Thanks!

From my tests, compositor does not affect it. It just takes very long time to reproduce. On nouveau, the fastest way to reproduce was (for reason unknown to me) enabling WrappedFB in xorg.conf. Then, I was able to reproduce it by moving windows for 10-15 minutes. On radeon, it was a bit harder. I used Xnee to move windows for me and let it run for about 10 hours. Then I checked the machine and could clearly see that any windows movement causes Xorg memory usage to increase by a few KB.

(In reply to Jan Janeček from comment #5)
> From my tests, compositor does not affect it. It just takes very long time
> to reproduce. On nouveau, the fastest way to reproduce was (for reason
> unknown to me) enabling WrappedFB in xorg.conf. Then, I was able to
> reproduce it by moving windows for 10-15 minutes. On radeon, it was a bit
> harder. I used Xnee to move windows for me and let it run for about 10
> hours. Then I checked the machine and could clearly see that any windows
> movement causes Xorg memory usage to increase by a few KB.

OK, thanks for that info.  Does locking the session cause the leaked memory to become available, or is it permanently lost even if the session is subsequently locked?

Thanks!

Locking the session seems to make it even worse:

When I don't move windows much before locking (thus have no leaked Xorg memory), the session locks immediately and everything seems ok.

When Xorg memory usage is increased by moving windows before locking, the session lock dialog takes about 20 seconds to appear - and during that 20 seconds, the Xorg memory usage slowly increases even more!

(In reply to Jan Janeček from comment #7)
> Locking the session seems to make it even worse:
> 
> When I don't move windows much before locking (thus have no leaked Xorg
> memory), the session locks immediately and everything seems ok.
> 
> When Xorg memory usage is increased by moving windows before locking, the
> session lock dialog takes about 20 seconds to appear - and during that 20
> seconds, the Xorg memory usage slowly increases even more!

Odd!  I'll probably have to put together a patch to test a theory I have, specifically that unprocessed events accumulate in the X server while the receiver cannot process them due to the receiving process (kdesktop_lock) sleeping.

Created attachment 2111 [details]
Disable reception of X11 events before sleeping

Can you try the attached patch for tdebase to see if it resolves the problem?

Thanks!

Applying the patch to 3.5.13.2 (had to change tqt-->qt) does not solve the problem. (I recompiled just the kdesktop_lock binary, hope that's enough)

(In reply to Jan Janeček from comment #10)
> Applying the patch to 3.5.13.2 (had to change tqt-->qt) does not solve the
> problem. (I recompiled just the kdesktop_lock binary, hope that's enough)

Yes, it is sufficient to recompile kdesktop_lock, though you would need to log out / log in for the changed binary to be used.

Strange that this did not work.  I know you mentioned the Xorg memory spiking when you engaged the screen locker; when you unlock the screen does the leaked memory stay or does it disappear?

Thanks!

In lockprocess.cc in LockProcess constructor, there is:
    XGetWindowAttributes(qt_xdisplay(), RootWindow(qt_xdisplay(), qt_xscreen()), &rootAttr);
    { // trigger creation of QToolTipManager, it does XSelectInput() on the root window
        TQWidget w;
        TQToolTip::add( &w, "foo" );
    }
    XSelectInput( qt_xdisplay(), qt_xrootwin(), SubstructureNotifyMask | rootAttr.your_event_mask );

If I comment out these lines, the problem seems to go away. (Notice the constructor is called in main() by "LockProcess process;" before suspending.)

(In reply to Jan Janeček from comment #12)
> In lockprocess.cc in LockProcess constructor, there is:
>     XGetWindowAttributes(qt_xdisplay(), RootWindow(qt_xdisplay(),
> qt_xscreen()), &rootAttr);
>     { // trigger creation of QToolTipManager, it does XSelectInput() on the
> root window
>         TQWidget w;
>         TQToolTip::add( &w, "foo" );
>     }
>     XSelectInput( qt_xdisplay(), qt_xrootwin(), SubstructureNotifyMask |
> rootAttr.your_event_mask );
> 
> If I comment out these lines, the problem seems to go away. (Notice the
> constructor is called in main() by "LockProcess process;" before suspending.)

Doubly strange that my patch did not work then; my patch is targeting the exact same mechanism.  Let me look into this further; I wonder if the X server did not acknowledge my request to disable reception of events.

Tim

(In reply to Jan Janeček from comment #12)
> In lockprocess.cc in LockProcess constructor, there is:
>     XGetWindowAttributes(qt_xdisplay(), RootWindow(qt_xdisplay(),
> qt_xscreen()), &rootAttr);
>     { // trigger creation of QToolTipManager, it does XSelectInput() on the
> root window
>         TQWidget w;
>         TQToolTip::add( &w, "foo" );
>     }
>     XSelectInput( qt_xdisplay(), qt_xrootwin(), SubstructureNotifyMask |
> rootAttr.your_event_mask );
> 
> If I comment out these lines, the problem seems to go away. (Notice the
> constructor is called in main() by "LockProcess process;" before suspending.)

Is it sufficient to comment out all lines except for the last XSelectInput, or does it also need to be commented for the bug to be resolved?

Thanks!

Commenting out XSelectInput was necessary. I tried moving it out of the constructor, and it looks the problem depends on whether it's called before or after app.processEvents(). When I add "app.processEvents();" right before sigsuspend, your patch seems to work.

Created attachment 2112 [details]
Disable reception of X11 events before sleeping

(In reply to Jan Janeček from comment #15)
> Commenting out XSelectInput was necessary. I tried moving it out of the
> constructor, and it looks the problem depends on whether it's called before
> or after app.processEvents(). When I add "app.processEvents();" right before
> sigsuspend, your patch seems to work.

OK, I could see that helping.  It seems I'm trying to force TQt3/Xlib to do something it was never really meant to do, so some...unusual calls are required.

So, just to verify, this patch fixes the problem for you?

Yes, that fixes it.

(In reply to Jan Janeček from comment #17)
> Yes, that fixes it.

All right, no adverse effects noted on my test box; pushed to GIT in hash 85afc59.

Thanks for reporting, and for your invaluable help in tracking this down!