search

sdhand / picom

A compositor for X11, active fork.
Other
136 stars 10 forks source link

Memory leak. #4

Open eepykate opened 4 years ago

eepykate commented 4 years ago

This fork seems to have a memory leak.

Specs:

(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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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

eepykate commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Ah sorry. I'll let you know.

eepykate commented 4 years ago

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

eepykate commented 4 years ago

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