#14047: Continuous music playback causes dramatic RAM usage
------------------------------+----------------------------
Reporter: dsuden | Owner: leavengood
Type: bug | Status: assigned
Priority: normal | Milestone: Unscheduled
Component: Kits/Media Kit | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
------------------------------+----------------------------
Comment (by ttcoder):
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 leak_analyser.sh didn't work
for him, and he'd need to submit a patch to review.haiku-os.org 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*
--
Ticket URL: <https://dev.haiku-os.org/ticket/14047#comment:11>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
