Suspected leak(s)

[ttcoder]

Spin-off from #11752:

When you run Haiku without interruption for days, ProcessController shows increasing memory usage for some apps.

We first realized about it by watching memory use for our apps, whose same versions didn't seem to leak in late 2014/early 2015 (or to rephrase, we didn't get reports from stations, whereas now they seem to need to reboot from memory exhaustion after a few days, which prompted us to run a 10 days test with the result below).

But it seems to also occur on Haiku apps (Deskbar, media_server ..etc), so time to start this ticket and gather more data, and confirm/infirm the suspicion.

Ticket to be dispatched to sub-tickets/modified/closed as invalid depending on outcome of data gathering.

[ttcoder]

To illustrate:

(we're running a similar test in an earlier hrev to see if it's context-dependant)

(also note that specifically in the case of SoundPlay, some data was collected using something like listarea SoundPlay | [grep heap] which I suppose is more accurate/useful than the PController figures?)

(dsuden is working on collecting data, unfortunately we're tied up with many things so it takes some very significant time, we're still at the pre-PM (hrev46104) stage of testing, and still testing SP instead of deskbar et al; Dane confirmed his testing finds a leak in SoundPlay, and told him I already knew about it since it was fixed only later in hrev46107 :-) (and it regressed again some time later, being first spotted 16 months later)

*EDIT*: Related ticket: Dario started work on cleaning up Deskbar, found a few small leaks already ..etc in #11934

EDIT2: 3-part hrev49018 leak fix noted, going to do a from-scratch test with the new hrev soon ; I wonder why that leak would manifest itself as a 196 bytes leak though, there must be something to add to my test case

[ttcoder]

Deskbar, media_server ... are above average.

[anevilyak]

You don't seem to have actually uploaded the image as an attachment, which is why the link doesn't work. In any event, if you can in fact confirm that the same exact application code doesn't exhibit this issue in an earlier time frame, then it'd be enormously helpful if you could bisect a more narrow time frame than several months as to when these symptoms start manifesting.

Edit: Fixed image code to point to the correct location.

[Barrett]

Don't know if it's related, but the ic_taskq seems to eat a very large part of memory, it happened when testing BBuffer proliferation things.

[waddlesplash]

In the past few weeks, Michael's managed to eliminate some cross-app leaks (e.g. vector icon code) -- how much of an improvement has there been?

[ttcoder]

We'll be sure to report back on this ticket ASAP though right now we are still in the 48000+ range unfortunately. The first system with 49000+ that was about to ship to a station failed Q.A. before going out the door (no audio output on the preview jack); so we had to revert back our "reference" image to the last known good one and started bisecting and digging but might be days or weeks yet.

[ttcoder]

D+0

[ttcoder]

D+5 : system-wide leak is gone (the rest is app specific)

[ttcoder]

test done in 49148

[ttcoder]

Looks very much to me like the system-wide (bpathfinder-wide ..etc) leaks are gone, reverting memory use to its historical Haiku norm, yay!

As to app specifics,

• I'll ask Dane what replicant add-ons he has in the deskbar, any deviations from the out-of-the-box config.
• Disappointed to see our two media-using apps not reverting to their historical norm, but that will take some analyzing and another ticket probably. I have a bookmark on mmlr's new leak checking tools, could come in handy.

Guessing this ticket could be closed as fixed maybe..