Creeping memory leak as files are played

kode54 commented

2022-01-29 00:10:27 -03:00

(Migrated from github.com)

Describe
As files are played, memory is continually leaked. I intend to investigate when the 7th arrives, but I can only guess that the virtual memory crap that is used for ring buffers by all stages of output is broken.

To Reproduce (delete if not applicable)
Steps to reproduce the behavior:

Play lots of files

Expected behavior
Memory should be relinquished when it's not in use.

Version information:*

macOS version: 12.2
Cog version: Latest as of this post

Additional context
I intend to rewrite the memory allocation used by the ring buffer code, to have a "shared" instance of an objective c class, which allocates only single blocks of memory in increments of 32MB, and doles out blocks of this to the caller, otherwise allocating and holding newer blocks if the current block(s) don't hold enough. It will deallocate whole blocks if all of their contained regions are freed.

None of this stupid double allocate virtual memory crap to try and get contiguous blocks. One larger block. 32MB should be enough for starters, since it needs 1MB per file decoding in the background, another 1MB per converter thread acting on those inputs, and 1MB for the output node, of which there will be one per restarted playback. Oh, and 4MB for when device format changes. There may be up to 30 seconds worth of files queued up in the background, which can be any arbitrary number, depending on how short the files in the list are.

**Describe** As files are played, memory is continually leaked. I intend to investigate when the 7th arrives, but I can only guess that the virtual memory crap that is used for ring buffers by all stages of output is broken. **To Reproduce** (delete if not applicable) Steps to reproduce the behavior: 1. Play lots of files **Expected behavior** Memory should be relinquished when it's not in use. **Version information:*** - macOS version: 12.2 - Cog version: Latest as of this post **Additional context** I intend to rewrite the memory allocation used by the ring buffer code, to have a "shared" instance of an objective c class, which allocates only single blocks of memory in increments of 32MB, and doles out blocks of this to the caller, otherwise allocating and holding newer blocks if the current block(s) don't hold enough. It will deallocate whole blocks if all of their contained regions are freed. None of this stupid double allocate virtual memory crap to try and get contiguous blocks. One larger block. 32MB should be enough for starters, since it needs 1MB per file decoding in the background, another 1MB per converter thread acting on those inputs, and 1MB for the output node, of which there will be one per restarted playback. Oh, and 4MB for when device format changes. There may be up to 30 seconds worth of files queued up in the background, which can be any arbitrary number, depending on how short the files in the list are.

reagle commented

2022-01-29 15:29:39 -03:00

(Migrated from github.com)

Yes, I've been having a problem with coreaudiod growing to 1GB+ from 18MB on Monterey and suspect cog is the culprit. Does that make sense, would the leak show up there in Activity Monitor?

Yes, I've been having a problem with `coreaudiod` growing to 1GB+ from 18MB on Monterey and suspect cog is the culprit. Does that make sense, would the leak show up there in Activity Monitor?

kode54 commented

2022-01-30 02:56:00 -03:00

(Migrated from github.com)

This was awful. Retention cycles on both the file inputs and the output device.

reagle commented

2022-12-06 18:41:04 -03:00

(Migrated from github.com)

I just had a recurrence of this with 2688-g37065adf on MacOS 13.0.1 (22A400). After being a way from the computer for some hours I'd come back to find Cog hung and coreaudiod up above a GB. I just installed 2722-g5e0a3308 and will report back if the problem continues.

Creeping memory leak as files are played #221