memory leak on raspberry pi

[GoogleCodeExporter]

The armv6hf squeezelite version 1.0rc2 seems to leak memory. I've seen this 
with the previous version I had installed as well (I think it was 0.96? I can't 
remember). The kernel's OOM killer kills the task when it reaches about 250 MB. 
The only output I have at the moment is the OOM messages; I realize that's not 
very helpful, so I'll gladly give you any other information that you may need, 
jet let me know what to do to get it.. Maybe run a debug version? It seems to 
reproduce all the time here now (after running for about a day), so it's a good 
opportunity to debug it.

Thanks!
Alex

Original issue reported on code.google.com by alext...@gmail.com on 11 Feb 2013 at 9:49

Attachments:

• squeezelite-oom.txt

[GoogleCodeExporter]

Can you confirm which codecs you are using.  Could you run with -d all=debug to 
show what it is doing?  I don't see memory leaking, but it could be different 
codecs.

Original comment by trio...@btinternet.com on 11 Feb 2013 at 9:59

[GoogleCodeExporter]

I'm now running it with -d all=debug. I'll post a comment with the resulting 
log once it crashes again. BTW the -f option doesn't seem to work, it's still 
writing the log to stdout, so I had to use redirection....

Original comment by alext...@gmail.com on 11 Feb 2013 at 10:10

[GoogleCodeExporter]

Hi,
I'm attaching the compressed log. The last line was repeated until the log grew 
to take up all the space on the device; I trimmed the repeating lines. I killed 
the process before the OOM did, and this is how it looked like before I killed 
it:

pi@kitchen ~ $ ps auwx|grep sq
pi        3595 19.8 81.4 272660 193796 ?       Sl   Feb11 333:44 /usr/local/bin 
squeezelite -o pulse -n kitchen -d all debug

So that's almost 200 MB of memory consumption (RSS).. It started out consuming 
8 MB, and grew. I hope the log helps. If there's anything else I can do, please 
let me know.

Thanks a lot for your help!
Alex

Original comment by alext...@gmail.com on 12 Feb 2013 at 2:17

Attachments:

• squeezelite.log.bz2

[GoogleCodeExporter]

Just wanted to add: the pattern of the memory growth doesn't seem to be linear. 
It doesn't start growing from the first moment. In fact, yesterday I looked at 
it all day and it always stayed at around 8 MB. Only today, when I looked, it 
suddenly was 200 MB. It appears to have happened in a moment. I hope the log 
can help finding it...

Original comment by alext...@gmail.com on 12 Feb 2013 at 2:22

[GoogleCodeExporter]

The very end of this log shows squeezelite unable to write to the device - is 
it possible that the memory growth happened at this time, or did you see any 
earlier than this?

Original comment by trio...@btinternet.com on 12 Feb 2013 at 3:01

[GoogleCodeExporter]

Are you talking about the last line?
output_thread:626 recover failed: Input/output error
Then yes, it may have happened then.. Indeed as I noted above, it appears that 
the growth happened quickly all at once, and not gradually during the whole 
runtime of the program. So this indeed might have caused it.
The line before it says that the ALSA lib couldn't recover from an underrun. 
Could it be that squeezelite doesn't handle this case well, and enters some 
kind of endless loop?

Original comment by alext...@gmail.com on 12 Feb 2013 at 3:08

[GoogleCodeExporter]

Hi,
Some more information. I saw that I had two more OOM events, before squeezeplay 
became so big, in which it is possible to see it growing. The first is for 
gmediarender, and the second is for pulseaudio to which squeezelite is sending 
its audio. Maybe that's when it got the ALSA error message... But it seemed to 
be growing before that.

Original comment by alext...@gmail.com on 12 Feb 2013 at 9:34

Attachments:

• oom-messages.txt

[GoogleCodeExporter]

Any chance you could avoid using pulse audio?  I found that just using that as 
the output caused a much larger memory footprint.  I can't see where 
squeezelite is allocating memory itself which is not bounded.  I suspect pulse 
may be part of the problem..

Original comment by trio...@btinternet.com on 12 Feb 2013 at 9:40

[GoogleCodeExporter]

The trouble with the Raspberry Pi is that playing audio directly to the sound 
device results, for some reason, in horrible quality, and playing through 
pulseaudio somehow fixes that. I'm not sure why that happens, but it seems to 
be common knowledge on the web... I admit I've never tried to run squeezelite 
directly, I will definitely try it.

In parallel, perhaps a helpful idea would be for you to give me a debug version 
of squeezeplay, which I will run, and then kill -6 to generate a core file when 
it's big in RAM, and then you'd be able to load it with gdb and see which 
structures have grown?

Original comment by alext...@gmail.com on 12 Feb 2013 at 9:46

[GoogleCodeExporter]

Hey,

Just wanted to update. Running directly, without pulseaudio, solves the memory 
leak issue. So I guess we can close this.

There's another problem now, that the raspberry starts outputting noise after a 
day or two (with the music just faintly heard behind it), but I'm not sure it's 
related to squeezelite, I think I've seen this mentioned somewhere, although I 
can't find it now. If you've seen/heard this somewhere, let me know, if not, 
I'll keep looking. Perhaps a USB audio device will solve it.

Thanks for sqeezelite and for your support!
Alex

Original comment by alext...@gmail.com on 24 Feb 2013 at 8:34

[GoogleCodeExporter]

Closing as a problem with pulse audio not squeezelite

Original comment by trio...@btinternet.com on 24 Feb 2013 at 10:00

• Changed state: Invalid

[GoogleCodeExporter]

I've come across this issue in both Raspbian and on Windows. In Raspbian, I'm 
using pulseaudio because I'm using both shairport and Squeezelite. These two 
programs cause problems with each other when trying to use the same ALSA device 
but not when they use pulse. The crash comes after error messages saying 
Squeezelite cannot access the device. I have not been able to trigger the 
problem manually. It happens on its own after running for a few days.

On Windows, Squeezelite does not crash but takes up quite a bit of memory. It 
also outputs an error that it cannot access my HDMI audio device for output. 
The error constantly repeats until I close Squeezelite. It seems this happens 
whenever I open Windows Media Center and start watching TV with Squeezelite in 
the background (though nothing is playing to it). Perhaps Squeezelite is 
running into a conflict accessing the same audio output as Windows Media Center.

Original comment by joey7...@gmail.com on 10 Apr 2013 at 7:56