Closed paravoid closed 3 years ago
@vkareh, I believe 6b05da5e49996a2101edfd703dd3f5d91011d726 was authored by you, so I'd appreciate your review. Thanks!
From quick look one more cairo_surface_destroy
call is missing...
@paravoid good find! I'm definitely seeing this leak aswell, as marco keeps getting slower and slower as time goes on..
@paravoid thanks very much for finding the culprit!!! Here is the fix for the missing leak fix mentioned by @muktupavels . Please note that cairo_surface_destroy
should be in fact called cairo_surface_dereference
. I think it can get checked-in both together, right? The numbers are no longer increasing for me:
xrestop - Display: localhost:0
Monitoring 28 clients. XErrors: 0
Pixmaps: 1551341K total, Other: 97K total, All: 1551439K total
res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier
0a00000 43 4 2 43 2295 1182574K 56K 1182631K 11489 marco
2a00000 28 7 1 27 115 220719K 4K 220724K 16081 Mozilla Firefox
Thanks all. I updated the commit to address these issues — hope that works.
Commit 6b05da5e49996a2101edfd703dd3f5d91011d726 introduced a Cairo surface leak, by calling
gdk_cairo_surface_create_from_pixbuf()
but then never freeing those surfaces withcairo_surface_destroy()
.This manifested in leaking resources when switching between virtual desktops, as observed using xrestop (
Pxms
column), which made the desktop slow and ultimately unusable after a few weeks of uptime.Fixes #685