[haiku-bugs] Re: [Haiku] #9458: Memory leak in BMediaFile -> BMediaTrack
- From: "Haiku" <trac@xxxxxxxxxxxx>
- To: undisclosed-recipients: ;
- Date: Tue, 27 Aug 2019 07:29:53 -0000
#9458: Memory leak in BMediaFile -> BMediaTrack
--------------------------+------------------------------------------------
Reporter: Robert S. | Owner: leavengood
Type: bug | Status: assigned
Priority: normal | Milestone: R1
Component: Kits/Media | Version: R1/Development
Kit |
Resolution: | Keywords: BMediaFile BMediaTrack memory leak
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
--------------------------+------------------------------------------------
Changes (by ttcoder):
* cc: mmlr (added)
Comment:
Replying to [comment:8 leavengood]:
I wrote a tool to analyze this data but there is so much memory left
"hanging" when you Ctrl-C
Ah, Ctrl-C.... This might be the reason that leak_analyser.sh has not
worked for you so far; @mmlr would know for sure (Cc'ing him), but
interrupting the program this way might behave the same as if it crashed,
as far as the guarded heap's output is concerned. And so it will appear as
if all resources have been freed "correctly" (as discussed off ticket),
with no leak analysis performed at all.
this app that it is hard to tell what the leaks are. I will try running
my memory tracker again with a version of this which only does a few loops
and then exits, so I get less memory usage left which is not truly leaks.
Right, replacing the infinite loop with a simple for() loop on a few
iterations might allow the guarded heap's "epilogue" functions to be
called properly, and output results so that leak_analyser.sh can be
brought to bear and pinpoint leaks directly. This might end up being a
significant shortcut from the other methods (patching libroot and so on).
A lot of stuff happens behind the scenes when you set up a BMediaFile
and a BMediaTrack, including loading the needed plugins, which in this
case is ffmpeg. It is also unloaded when those are deleted, so each
iteration of the above loop loads, then unloads ffmpeg.
Which is probably going to construct/destruct lots of heavy objects (might
even include the AddOnManager ..etc).
Running this code in a loop like this is certainly a pathological case,
but I am still shocked how much happens behind the scenes.
Well, MediaPlayer (or SoundPlay) by design is going to create a
BMediaFile/Track for each mp3 it wants to play (or keep the object around
but call its SetTo() method for each file, which amounts to the same
thing) so this looks good to me, seems you found a shortcut test for
simulating a recording (or playback) test in an accelerated fashion :-)
What also might be important here is that this code does not use the
BMediaRoster, and any leaking it does might be from the assumption that
BMediaRoster will always be there to clean up when a program is done using
the Media Kit.
IIRC the roster handles only the BMediaNode side of things (cleans up time
sources related to BSoundPlayer etc), but BMediaFile is on the other side
of the "fence" so to speak, compared to BSoundPlayer.
Again, I will know more when I find the source of leaks here, which
hopefully I will. But I am not exaggerating when I say each iteration of
this loop probably has many 1000s of allocations, so it is tricky to sort
through.
If you end up using leak_analyser.sh (and maybe a short for() loop is all
it will take to allow for it) you'll see things are much easier :-) though
it still will give you a headache or ten going through the (reduced)
output. Back when I had done that the results hinted at AddonManager and
stuff, but YMMV, we'll see.
--
Ticket URL: <
https://dev.haiku-os.org/ticket/9458#comment:11>
Haiku <
https://dev.haiku-os.org>
The Haiku operating system.
Other related posts:
