#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
--------------------------+------------------------------------------------
Comment (by leavengood):
To provide some update, the TestMethod in this DebugApp is the following:
{{{
void
DebugClass::TestMethod() {
do {
fData = new BMallocIO();
fMediaFile = new BMediaFile(fData, &fMediaFileFormat);
fMediaTrack = fMediaFile->CreateTrack(&fInputFormat,
&fCodec);
fMediaFile->CommitHeader();
fMediaTrack->SetQuality(1.0);
fMediaFile->ReleaseAllTracks();
fMediaFile->CloseFile();
delete fMediaFile;
delete fData;
snooze(1000);
}while(true);
}
}}}
snooze take microseconds, so this only "pauses" for 1 millisecond, and if
you run this code as is, it will quickly crash Haiku, at least it did for
me in a VM with 2 GB of RAM.
Switching to 1000000 (1 second) for the snooze helps, but each iteration
adds to memory usage by quite a bit.
fMediaFileFormat and fInputFormat are set up to be raw video in avi files
with a mpeg4 codec.
At the suggestion of waddlesplash I added code to libroot to log memory
allocations including the image and symbol of the caller, and I ran that
with this DebugApp for a few seconds. The amount of data is hard to
describe, but it is a lot (many MBs of text.) I think I ran this against
the version with the short sleep and that is probably why I get so much
data. I just did a quick look and I think there are 109 iterations of this
loop in my test run, and the resulting "log" of the output for memory
usage is a 14 MB text file.
I wrote a tool to analyze this data but there is so much memory left
"hanging" when you Ctrl-C 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. Now that I say this it sounds obvious but I
was getting tired on Saturday night when I was looking at this :)
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. Every time you load ffmpeg, it
loads the gnutls library, and that seems to have a lot of set up, and I
see many, many calls to asn1_perror and asn1_find_node from the libtasn1
library, which I assume is due to some bugs in our Haiku port of this
library. Or maybe not, it is hard to tell, but asn1_perror is supposed to
log an error to stderr but I don't see anything logged. And it might be
fine that these do a lot of small allocations when gnutls is set up.
Overall this should be looked into, but is certainly not the core problem
here.
Running this code in a loop like this is certainly a pathological case,
but I am still shocked how much happens behind the scenes.
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. 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.
As one final concern, the leak I find here, if any, might not be the one
generally plaguing us for normal media playback, though I sure hope it is
the same...
--
Ticket URL: <https://dev.haiku-os.org/ticket/9458#comment:8>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
