Opened 21 months ago

Last modified 13 days ago

#14047 assigned bug

Continuous music playback causes dramatic RAM usage

Reported by: dsuden Owned by: leavengood
Priority: normal Milestone: Unscheduled
Component: Kits/Media Kit Version: R1/Development
Keywords: Cc: ttcoder, mmlr
Blocked By: Blocking:
Has a Patch: no Platform: All


Building up a playlist of songs and leaving it running in Haiku results in a memory leak that could flood a medium sized village within a day. :-) I assume, from the behavior I'm seeing, that each time a new song starts, it leaks a bit more RAM. After 24 hours, I've seen memory consumption over 400MB, and it just keeps going up, the longer the program (MediaPlayer or SoundPlay) is left open and running song after song. This is a serious problem for anyone (like me) who needs the OS to play music for days, weeks, or longer, nonstop.

Change History (11)

comment:1 by diver, 21 months ago

Which process consumes memory? MediaPlayer? Take a screenshot of ProcessController.

comment:2 by cocobean, 18 months ago

Tested: hrev52013 x86_64

Monitored with ProcessController - Memory Usage -> MediaPlayer

MediaPlayer gains about 3MB/hour of consistent audio playback time. App errors/warnings show specific buffer(s) being filled up, but not released umtil application start/exit - not refreshing buffers between each playlist entry or playlist loop.

Last edited 18 months ago by cocobean (previous) (diff)

comment:3 by ttcoder, 8 months ago

Cc: ttcoder added
Component: - GeneralKits/Media Kit
Owner: changed from nobody to Barrett

comment:4 by Barrett, 8 months ago

This is the usual buffer management issue, or at least related to it.

I've been working on that, and I had a WIP, I even offered my help to someone and I was gifted with being accused (once again) for introducing a bug which was there at least 6 years before I even had commit access. The result of how the thing has been handled, is that I'm not going to contribute any information about the resolution of any media kit bug. I just can't continue to bear the situation.

I'm not even an Haiku developer anymore, so there's no hope I will fix that.

comment:5 by korli, 8 months ago

Owner: changed from Barrett to nobody
Status: newassigned

comment:6 by leavengood, 4 months ago

Owner: changed from nobody to leavengood

I am now looking at these sorts of issues.

comment:7 by ttcoder, 4 months ago

Thanks for looking at this one Ryan

This one's easy to setup a test for (just launch MediaPlayer with a big playlist) though it takes time to build up heap consumption

(with a bit of luck, maybe the "time consuming" part can be eliminated by building/releasing a BMediaFile+BMediaTrack pair at full speed a thousand time? see e.g. the .cpp code in #9945 and #11752)

Very curious to see if my patch changes the leak figures, i.e. if less heap is leaked after 1000 iterations.

(EDIT: as to leaked buffers, that's a different/unrelated bug, relating to areas rather than heap, and which I believe was fixed in #14755 thx Ryan for that one)

Last edited 7 weeks ago by ttcoder (previous) (diff)

comment:8 by ttcoder, 2 weeks ago

Cc: mmlr added

In recent hrevs I'm unable to work on this, as no longer works.

I've been told to upgrade to a recent hrev, as media leaks are reportedly fixed there. We know our apps still leak, so I need to validate that assessment, or find out /who/ is leaking, if not media -- but I'm unable to, as the guarded heap no longer outputs *anything* at all on exit, so has nothing to analyse.

That problem has been confirmed by mmlr, who points the finger at changes in runtime_loader (?)

We've been stuck for weeks on this.. Looks like another cycle of "let it rot" is starting for us..

(edit) @michael thanks much for chiming in below! @waddlesplash appreciate if you can take a look at the link between the breakage and the commit

(edit2) mmlr suggested linking against libroot debug and calling the dump directly, should do the trick until the 'real' fix

Last edited 2 weeks ago by ttcoder (previous) (diff)

comment:9 by mmlr, 2 weeks ago

Specifically 354b60af29b2cb24d8d02265f83e44c9bfdf8005 as part of hrev52813 breaks the dump on exit feature (which is called from __heap_terminate_after, which is called from terminate_after of libroot_debug). The breakage is not obvious to me, since this should now simply be called from the runtime_loader directly, but it is now not called at all. Whether or not this is related to libroot_debug usually being loaded using LD_PRELOAD, I have not been able to test due to severe time constraints.

comment:10 by waddlesplash, 2 weeks ago

Well, I am pretty sure leavengood was using the leak analyser recently, so I'm mildly surprised it doesn't work... Maybe I'm mistaken and he wasn't using it.

comment:11 by ttcoder, 13 days ago

Confirming : Working with CC6, on

	Haiku shredder 1 hrev53561 Oct 23 2019 18:23:49 x86_64 x86_64 Haiku

I get no output using the guarded heap the normal way; I've had to hardcode a call to

	heap_debug_dump_allocations(false, -1);

at the end of main() as a work-around. That plus a couple other factors caused a little bit of time consuming trouble, but in the end mmlr's workaround helped me to get back on track until runtime_loader is fixed.

Now that I get to analyse the leaks again, things get interesting: there is almost zero incremental leaking when CC6 goes from one mp3 to the next (just an 80-something leak, discussed with mmlr as being completely harmless to our use-case). So I have to coordinate with Dane, see if he still gets MBs/day leaks or not, and if so, why I don't see that here (at least with the guarded heap and the work-around and my audio setup).

P.S. -- for Ryan I only have his public ticket stuff and emails to go by, and judging by those he kept mentioning how didn't work for him, and he'd need to submit a patch to that implements the guarded heap another way; now I'm starting to wonder if what he was seeing, was actually the same runtime_loader bug we're discussing above ? If so, a bit of a shame that he wasted his time looking at a different way, when it was just a matter of fixing the runtime_loader bug to start with ? This probably warrants further investigation *g*

Note: See TracTickets for help on using tickets.