Frequent coredumps during MP3 playback about squeezelite

[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 [email protected] 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 [email protected] on 5 Jan 2015 at 7:36

[GoogleCodeExporter]

Captured a log.  Attached.

Original comment by [email protected] 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 [email protected] on 5 Jan 2015 at 10:35

[GoogleCodeExporter]

Here you go.  Thanks!

Original comment by [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 7 Jan 2015 at 12:46

[GoogleCodeExporter]

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

Original comment by [email protected] on 7 Jan 2015 at 1:52