Frequent coredumps during MP3 playback

[GoogleCodeExporter]

What steps will reproduce the problem?

Playing back FLAC files doesn't cause any issue.  MP3 files, however, do.  
After awhile, it will segfault.

What version of the product are you using? On what operating system?

Squeezelite 1.6.4 on Debian jessie x86_64

Please provide any additional information below.

I also filed this in the Debian BTS at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774524

Core was generated by `squeezelite -a 200 10 -d output debug -o dmix -u
hLX'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f09756a6bbc in resample_drain (process=0x7f09758b3600
<process>) at resample.c:108
108        clip_cnt = *(SOXR(r, num_clips, r->resampler));
(gdb) bt
#0  0x00007f09756a6bbc in resample_drain (process=0x7f09758b3600
<process>) at resample.c:108
#1  0x00007f09756a6411 in process_drain () at process.c:109
#2  0x00007f097569abd0 in decode_thread () at decode.c:87
#3  0x00007f09752530a4 in start_thread (arg=0x7f0975615700) at
pthread_create.c:309
#4  0x00007f097258bccd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb)

(gdb) print r
$1 = (struct soxr *) 0x7f09767729c0
(gdb) print r->resampler
$2 = (soxr_t) 0x0

Original issue reported on code.google.com by rm.rf.do...@gmail.com on 5 Jan 2015 at 2:57

[GoogleCodeExporter]

Are you able to reproduce at will?  If so could you enable logging of the 
decode thread: "-d decode=debug"

I don't initially see how this state happens as resample_drain is only called 
within the decode thread.  Other callers which may set r->resampler to 0 should 
be called with a mutex set which is help when resample_drain is called.

Which mp3 codec are you using?

Original comment by trio...@btinternet.com on 5 Jan 2015 at 7:12

[GoogleCodeExporter]

I cannot reproduce it instantly, but I can reproduce it within 30 minutes 
nearly 100% of the time.  I will get that log.

I haven't passed along any options on which MP3 library to select, so I guess 
the default?  Any particular way to find out which it's using?  (Perhaps that 
logging will do it)

Original comment by rm.rf.do...@gmail.com on 5 Jan 2015 at 7:36

[GoogleCodeExporter]

Captured a log.  Attached.

Original comment by rm.rf.do...@gmail.com on 5 Jan 2015 at 8:04

Attachments:

• squeezelite.log

[GoogleCodeExporter]

Thanks.  I've not been able to reproduce over the last hour.

I can protect that part of the code easily, but I want to understand why it 
gets there as I was not expecting a second call of drain.  I'm speculating that 
there's a slimproto message which changes the state of teh decode process at 
the relavent point.

Is there any change you could do a log with "-d all=debug".  This should help 
me understand what is going on...

Original comment by trio...@btinternet.com on 5 Jan 2015 at 10:35

[GoogleCodeExporter]

Here you go.  Thanks!

Original comment by rm.rf.do...@gmail.com on 5 Jan 2015 at 11:14

Attachments:

• squeezelite.log.gz

[GoogleCodeExporter]

An update - I have now duplicated this with FLAC files as well.

Also, it happens on both of my x86_64 machines, but not on my Raspberry Pi, of 
a wonder.

Original comment by rm.rf.do...@gmail.com on 6 Jan 2015 at 2:34

[GoogleCodeExporter]

Thanks - looks like it receives an strm u message from the server after it has 
decoded the file.  I'm not currently sure what creates this - I can't do it 
from my server under normal playback...

Anyway the attached patch should help.  I want to do some testing of this as it 
is changing what I now consider to be a bug in the decode state machine.  It 
also protects against errors from libsoxr which is probably actually enough to 
fix the crash.

Any chance you could try it with and without the changes to resample.c?

Original comment by trio...@btinternet.com on 6 Jan 2015 at 9:01

Attachments:

• decodestate.patch

[GoogleCodeExporter]

So far, it looks good without the resample.c patch.  I will now retry with it 
and let you know.

Original comment by rm.rf.do...@gmail.com on 7 Jan 2015 at 12:46

[GoogleCodeExporter]

And indeed, it is also looking good with the resample patch.

Original comment by rm.rf.do...@gmail.com on 7 Jan 2015 at 1:52