Memory use grows over time - maybe uncapped?

Love the simplicity of the app but I noticed that it takes more memory the longer that it runs.
After 2 weeks its using almost 3gb on my laptop. Is this expected?

10 days later and usage is up another 25%. Doesn't look like a leak.
Is there is a list of apps & icons which grows over time and never gets emptied?

[sparr]

Mine is using 2GB after just a few hours.

1 day after a reboot I'm at 123MB.
Please tell me if this doesn't count as an issue, but for a neat little app I am surprised at such high mem usage.
I have a cloudbook with 2gb ram which just about runs a xfce and a browser but it couldn't do alttab for long?

Not trying to brag but I'm up to 12.8GB now. Am I doing something wrong?

[sagb]

Obviously it's memory leaks. Do you run latest alttab release? Numerous leaks were fixed in both 1.4.0 and 1.5.0.

I was on 1.4.0. Upgraded to 1.5.0 after your reply. Since then I've managed an 11 day streak and I got up to 3GB usage, which roughly tallies with the first screenshot here. Will report back again when I can get up to 30 days! Is there any other useful info I can provide?

[sagb]

Could you please upgrade to latest commit in master, start it, and then after some hours (i think it's not necessary to wait for days) send it SIGUSR1 signal, like: killall -USR1 alttab. alttab will print debug information, send it to me.

[sagb]

(It will print not in GUI window, but in terminal where it was started.)

[jfrob]

I'm not completely sure this is exactly the same issue. I noticed some rather excessive memory usage with alttab-1.5.0 as well, so I ran it through Valgrind memcheck for some time.

==574== LEAK SUMMARY:
==574== definitely lost: 5,744,163,380 bytes in 14,435 blocks
==574== indirectly lost: 52,705 bytes in 476 blocks
==574== possibly lost: 446,464,762 bytes in 222 blocks
==574== still reachable: 581,114 bytes in 4,012 blocks
==574== suppressed: 0 bytes in 0 blocks

Looking at the log (attached), seems there is quite a bit of leaking and much of it from this function:

alttab/src/win.c

Line 192 in a4d8ee9

int addIconFromProperty(WindowInfo * wi)

Full log here: alttab_valgrind.log

[sagb]

Thank you, @jfrob. I've managed to reproduce two top leaks from your valgrind run. The memory that is being allocated for each icon is limited for speed (related: #85). When the application has huge icons (1024x1024), this triggered a bug: the allocated memory was not freed.

Fixed in 1.6.0 (cb7dd8f), any testing are welcome.

That's awesome. Many thanks @jfrob for the valgrind info. I think the 1.6.0 patch has done it

@sagb apologies for the radio silence, I saw jfrob's reply and let this slip through my inbox.
I've run 1.6.0 for a while and it looks like you've cracked it cheers.
Here's my debug info (1.6.0) in case its useful for confirmation
debug information: winlist: 0 elements of 320 bytes, 0 total sortlist: 21 elements of 24 bytes, 504 total icons: 281 elements of 1184 bytes, 332704 total option_wm: 1, option_desktop: 1, option_screen: 1 option_font: 'Rajdhani:9' option_tileW/H: 120x140, option_iconW/H: 120x80 option_vp_mode: 0, vp: [1920x1080+0+0], has_randr: 1 option_positioning: 0, option_posX/Y: 0, 0 option_iconSrc: 2, option_theme: 'hicolor' ewmh: wmname 'i3', tslf 1, -1du 0