search

gopxl / beep

A little package that brings sound to any Go application. Suitable for playback and audio-processing.
MIT License
287 stars 13 forks source link

Potential Memory Leak? #193

Open yekyam opened 2 weeks ago

yekyam commented 2 weeks ago

Hi y'all, I recently started learning Go, and I wanted to build a small local music player.

Long story short, after running pprof on my program, I get this when I run it on /pprof/heap:

Showing top 10 nodes out of 29
      flat  flat%   sum%        cum   cum%
 6780.27kB 50.16% 50.16%  6780.27kB 50.16%  github.com/hajimehoshi/go-mp3.(*Decoder).ensureFrameStartsAndLength
 2593.27kB 19.19% 69.35%  4665.36kB 34.52%  github.com/hajimehoshi/go-mp3/internal/frame.Read
 2072.09kB 15.33% 84.68%  2072.09kB 15.33%  github.com/hajimehoshi/go-mp3/internal/maindata.getScaleFactorsMpeg1

(Hopefully) I am closing any beep.StreamSeekCloser, but of course I could be wrong. If needed, I'd be happy to attach any relevant code.

MarkKremer commented 1 week ago

Hi there :wave:

Could you help me understand why this indicates a memory leak and not just memory usage? What I understand of pprof/heap is that it's a snapshot of the memory usage on the heap at a specific time, but it may be released just a moment after. Is this called after Close was called? A code example and the the timing of the heap profile creation could help.

Some context: ensureFrameStartsAndLength is called when a new Decoder is made. At that point the whole MP3 is scanned through to make a seektable. This is needed for seeking because MP3 doesn't have a seektable embedded in the file itself. So it does a bit of work upfront but those bytes shouldn't stick around for long.