Hunting memory leaks in Vala

[kousu]

I left Dino running for 12 hours and it became the single largest consumer on my system, at nearly 1GB:

I’m sure this is a leak. Nothing is ever heavier than the web (or gnome itself).

I am trying to figure out how to hunt this down. Dino is a fairly large code-base so I need some tips on narrowing the search. I suspect it is accidental reference loops so I’m not even sure if valgrind or massif would be able to find the problems.

I tried heaptrack and got confusing results, with the top lines telling me the leaks are in gtk4. But I think the real problem is in some callbacks that gtk4 has been asked to call.

The one obvious target in my sample is

I went chasing that but was not able to squash it. I think there’s a leak somewhere in this file but I don’t know where yet.

Is heaptrack the right tool for this? Is there a native way to get a report of unfreed vala objects at exit? Right now now all I have is a muddle of locations that allocated leaked objects.

I’m hoping I can make this process efficient enough to actually find all the leaks before we stop using IPv4.

[bugaevc (Sergey Bugaev)]

A rather well-known issue is that Vala lambdas currently capture this from the containing method by a strong reference, often creating a reference cycle.

Unnecessary capturing of this/self can introduce unexpected memory leaks (#957) · Issue · GNOME/vala

Have you ruled that out?

[kousu]

No I have not. That definitely seems likely, there’s a lot of lambdas in this code. Thank you!!

I don’t know how I would prove it though because I’m not sure how to use my tools well enough to demonstrate anything.