Memory leak during search?

[aeghn]

When searching, the memory goes up very fast.

I suspect that this is a problem with ListStore

[neithern]

Not really leak, the app load visible music's cover only, when searching, more music's cover are loaded, and cached in memory.

[aeghn]

Thanks for your reply.

But I would also like to ask, when will this memory be freed?

$ echo "$(cat /proc/$(pgrep g4music)/statm | awk '{print $2}') * 4 / 1024" | bc
604

g4music has taken up 604MiB (about four hours of use).

[neithern]

How many music files in your case? how many files with album cover? The app caches recently used cover in memory, so it depends on the file numbers.

[aeghn]

Sorry for the late reply.

I made a video for it.

https://github.com/neithern/g4music/assets/51843252/ba58cafc-a834-4fae-899a-9046881998c5

You can see that the memory usage has stabilized as I scroll through the playlist.

But as soon as I start doing searches, the memory starts to skyrocket and it doesn't go down either.

I've found the same phenomenon in many other projects that use the liststore, including https://github.com/euclio/fm(rust) and https://gitlab.gnome.org/World/amberol(rust), so I think this is a bug in gtk.

[neithern]

原来你也是讲中文的，我们就用中文交流吧： 看你录的视频，只有100个不到的文件，这种情况下，G4Music会很快把所有文件的缩略图加载并缓存。据我所知，Amberol会在添加文件时加载所有缩略图，所以如果这种情况也会发生的话，那大概率就是ListStore或ListView的bug了。 我会再调研一下这个的原因。 感谢！

[aeghn]

我最近也在写一个基于 gtk4 的 launcher（里面也用到了 ListStore），因为我发现我的启动器有内存泄漏这个问题才开始看其他使用 gio::ListStore 是如何处理的。但是我发现我看到的项目几乎都有内存泄漏这个问题。

并且和一些常见的播放器使用 ListView + FilterModel 不同的是，因为启动器可能要涉及很多和其他应用交互的数据（比如计算器，剪切板，词典，Hyprland 程序切换），所以这个列表的数据的范围是不确定的。

也就是说当输入发生变化时，我先使用 gio::ListStore::remove_all 清空全部内容，然后再添加新的内容。

因为我并不熟悉 gtk 开发，很多东西都在摸索。所以我直到现在都不清楚上面的用法是不是一个好实践。😂

[neithern]

可以把你微信号发我：neithern@outlook.com

[aeghn]

抱歉，平时不咋用微信，tg 是 @sakalaka3212