Memory leak.

[eepykate]

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]

@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)

[sdhand]

@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?

[eepykate]

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

[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.

[sdhand]

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?

[eepykate]

Ah sorry. I'll let you know.

[eepykate]

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

[eepykate]

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