Memory leak - MediaPlayer

[kim1963]

Memory leakage when playing audio files with a MediaPlayer. Playing a big singular file. All audio formats create a leakage of memory. Reproduction of video files does not lead to a memory leak . Checked for 64 bits 57367 night build.

[Starcrasher]

Originally reported here ​https://discuss.haiku-os.org/t/memory-leak-mediaplayer/ Note that when kim1963 says a big file, it's about an eleven hours of audio.

[waddlesplash]

Looks like this may be a kernel leak and not a userland one.

Is this reproducible in any VMs or only on bare metal?

[kim1963]

Replying to waddlesplash:

Looks like this may be a kernel leak and not a userland one.

Is this reproducible in any VMs or only on bare metal?

Perhaps the code check with a static analyzer can clarify something?

[kim1963]

I checked large audio files in other player / QMplay2 and QMMP /. There are no problems with the memory leak.

[victroniko]

Can confirm this looks like something kernel/MediaKit related: i'm seeing the same behavior in StreamRadio. If left running and playing a stream, RAM usage climbs steadily without stop. Bug is easily reproducible this way.

I'm listening some music now, it's been ~20min and RAM usage is nearing 850MB. (edit. hrev57353, baremetal)

[kim1963]

Replying to waddlesplash:

Looks like this may be a kernel leak and not a userland one.

Is this reproducible in any VMs or only on bare metal?

On bare metal.

Unfortunately, I have no way to check it in a virtual machine.

[waddlesplash]

Does RAM usage go back down once MediaPlayer/StreamRadio is closed?

[kim1963]

Replying to waddlesplash:

Does RAM usage go back down once MediaPlayer/StreamRadio is closed?

Yes

[tzu_mi]

Hrev 57365, x64, bare metal Memory usage keeps growing playing tracks in loop or playing playlists

[pulkomandy]

For StreamRadio the rssue is possibly different: the entire stream is kept in memory forever due to the way the media kit implements http streams.

Also, I don't seewhy this would point to a kernel problem in either case, more likely it is a media kit (or network kit in the case of streamradio) problem.

In any case pl ase report the streamradio problem to StreamRadio bugtracker first, it is not a good idea to investigate two possibly related but different issues in the same bugreport (we can't split a bugreport in trac, but we can always close one bugreport as aduplicate of another if they end up being the same)

[madmax]

Replying to pulkomandy:

For StreamRadio the rssue is possibly different: the entire stream is kept in memory forever due to the way the media kit implements http streams.

I can confirm that. I saw it and even started rewriting it back when StreamRadio got a bit of attention due to the removal of some deprecated API, but other issues got in the way. There's already a ​report in its bugtracker.

[victroniko]

Replying to pulkomandy:

In any case pl ase report the streamradio problem to StreamRadio bugtracker first, it is not a good idea to investigate two possibly related but different issues in the same bugreport (we can't split a bugreport in trac, but we can always close one bugreport as aduplicate of another if they end up being the same)

I spun up two VMs, one with Beta4 and another with hrev57367. Installed StreamRadio and started the same stream on both VMs. After 1hr of streaming, RAM usage sits at ~350Mb on Beta4, and nearing 2Gb on said nightly. So I still think there's something wrong @ OS-level, and maybe both leaks add up?

In any case I won't test w/StreamRadio anymore (until needed/asked for), to isolate that issue.

[kim1963]

Replying to waddlesplash:

Looks like this may be a kernel leak and not a userland one.

Is this reproducible in any VMs or only on bare metal?

I checked the memory leak on the release of 64 bits 56578+93 - there is no memory leakage!

[pulkomandy]

Moving to r1beta5 since it's a regression

[jackburton]

Any chance this commit could be the culprit? ​https://github.com/haiku/haiku/commit/9858be4f63c2148aa18bd65e139586e3e837f8c2

[korli]

Replying to jackburton:

Any chance this commit could be the culprit? ​https://github.com/haiku/haiku/commit/9858be4f63c2148aa18bd65e139586e3e837f8c2

Please someone test with a hrev before hrev57350.

[victroniko]

Testing MediaPlayer side-to-side on fresh Haiku VMs, with a sample ~35min 85Mb ​MP3 file:

hrev57346: No apparent leak, RAM usage stays on ~22Mb after 15+ min. Fast seeks do not increase memory usage.

hrev57352: Very obvious leak, RAM usage ~100Mb after 3min and climbing at ~0.5Mb/sec. Fast seeking increases leakage to ~2Mb/sec.

[jackburton]

I suspect we need to call av_frame_unref AFTER we call avcodec_receive_frame().

At least, that's why I understand from here:

​https://stackoverflow.com/questions/37907194/audio-decoding-memory-leak-ffmpeg

[pulkomandy]

I suspect we need to call av_frame_unref AFTER we call avcodec_receive_frame().

That's already what should happen: the frame can be dereferenced just before decoding the next one, when _DecodeSomeAudioFramesIntoEmptyDecodedDataBuffer is called again.

But something is clearly not working as I think here?

[jackburton]

Replying to pulkomandy:

I suspect we need to call av_frame_unref AFTER we call avcodec_receive_frame().

That's already what should happen: the frame can be dereferenced just before decoding the next one, when _DecodeSomeAudioFramesIntoEmptyDecodedDataBuffer is called again.

Right, I see now.

[korli]

Replying to pulkomandy:

But something is clearly not working as I think here?

At least calling memset() then av_frame_unref() doesn't make sense.

[waddlesplash]

There's some other problem here though, because it's kernel memory usage that's increasing, not application memory usage. What's up with that?

[korli]

Proposed patch ​https://review.haiku-os.org/c/haiku/+/7108

[waddlesplash]

because it's kernel memory usage that's increasing, not application memory usage

At least ProcessController doesn't show kernel memory usage increasing, so maybe there's some problem with the other screenshotted application.

[waddlesplash]

Fix merged in hrev57382.