[prev in list] [next in list] [prev in thread] [next in thread]
List: haiku-bugs
Subject: [haiku-bugs] Re: [Haiku] #14047: Continuous music playback causes dramatic RAM usage
From: "Haiku" <trac () haiku-os ! org>
Date: 2019-11-25 10:12:59
Message-ID: 057.4a762fd960feb903bd5efd6341926930 () haiku-os ! org
[Download RAW message or body]
--===============2647598320824384225==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
#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.
--===============2647598320824384225==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic