picom icon indicating copy to clipboard operation
picom copied to clipboard

Memory leak.

Open eepykate opened this issue 5 years ago • 8 comments

This fork seems to have a memory leak.

Specs:

  • Nvidia GTX 1050
  • Intel Pentium G4560
  • 8G ram
  • arch linux btw

(btw I've had this issue for a while, it's not an issue with the most recent pr)

A memory log thing I made the other day. I once had it reach 600+ M used (Or was it 200M, I think it was 600M but I can't find a screenshot of it.)

I used the command pmap <compton PID> > <file> to get the memory usage.

>> tail -n 1 ~/opt/compton*
==> /home/cat/opt/compton-2019-12-18_05-19am.txt <==
 total            64252K

==> /home/cat/opt/compton-2019-12-18_05-26am.txt <==
 total            66668K

==> /home/cat/opt/compton-2019-12-18_05-36am.txt <==
 total            71752K

==> /home/cat/opt/compton-2019-12-18_05-56am.txt <==
 total            78796K

eepykate avatar Dec 19 '19 18:12 eepykate

@sdhand

Seems like everytime he requests something, xcb gives him a cookie, and then he needs to call request_reply(cookie), and the result to that needs to be free'd, which he never does.

      auto randr_version = xcb_randr_query_version_reply(
        c, xcb_randr_query_version(c, XCB_RANDR_MAJOR_VERSION, XCB_RANDR_MINOR_VERSION),
        NULL);

for example
Line 20 in driver.c
xcb_randr_query_version returns a cookie.
xcb_randr_query_version_reply uses that cookie, allocates some struct and hands that to him.
He never free's that struct.
Shuld be relatively easy to fix.
Very tedious though, as that probably happens everywhere throughout the project.

From @buffet on discord

Log: https://0x0.st/zdHJ.txt

(From using
valgrind --leak-check=full --log-file=$HOME/opt/valgrind.log --track-origins=yes /home/cat/opt/git/compton/build/src/compton with a --buildtype=debug version of this project)

eepykate avatar Jan 02 '20 22:01 eepykate

@GaugeK Finally got round to taking a look at this. I have a feeling that @ibhagwan's work which I merged in might have already fixed the problem, but I patched up a few leaks elsewhere also. Any chance you could confirm if you still see this behavior on the latest commit?

sdhand avatar Apr 03 '20 19:04 sdhand

Sorry for late reply, but I'll check it out.

eepykate avatar Apr 06 '20 05:04 eepykate

It still seems to have a memory leak, I'm using the GLX backend this time.

I can just spam my bind to open a term and it goes up.

eepykate avatar Apr 06 '20 06:04 eepykate

The glx backend is still very much WIP (and mainly being worked on by @ibhagwan, not myself) I make no promises about lack of memory leaks in there currently.

Can you confirm if the original leak in the xrender backend still exists or not?

sdhand avatar Apr 06 '20 12:04 sdhand

Ah sorry. I'll let you know.

eepykate avatar Apr 07 '20 05:04 eepykate

After spamming terminals the memory doesn't seem to go up much. So it seems to be fixed.

eepykate avatar Apr 07 '20 05:04 eepykate

Alright, after leaving it for a bit, it went up from 16M to 18M. But that's better than it used to be.

eepykate avatar Apr 07 '20 06:04 eepykate