Crash with long file names

[Anonymous]

I have svn-1696 running on a Fedora 7 machine.
While playing the music (on a Roku M1001) I noticed that the firefly server sometimes crashed.

After some investigating I concluded that the crash happens when:

– transcoding (flac files to wav)
AND
– the complete file name/path of the song file is rather long (approx 127 or longer)

When I make the file name shorter: no problem
When playing mp3 with long file names (no transcoding): no problem
Manual decoding of flac files with long file names (with flac command): no problem

The error message I see is as follows:

*** buffer overflow detected ***: /usr/sbin/mt-daapd terminated
======= Backtrace: =========
/lib64/libc.so.6(__chk_fail+0x2f)[0x3c094e4a3f]
/usr/sbin/mt-daapd(util_vasprintf+0xac)[0x42242c]
/usr/sbin/mt-daapd(pi_log+0x8f)[0x413b6f]
/usr/lib64/mt-daapd/plugins/ssc-script.so(ssc_script_open+0x177)[0x2aaaaace3ca7]
/usr/sbin/mt-daapd(plugin_ssc_transcode+0x9c)[0x423d4c]
/usr/sbin/mt-daapd(pi_stream+0x2ff)[0x41440f]
/usr/lib64/mt-daapd/plugins/rsp.so(plugin_handler+0x224)[0x2aaaaaee7df4]
/usr/sbin/mt-daapd(ws_dispatcher+0x5e4)[0x40e1b4]
/lib64/libpthread.so.0[0x3c0a0062f7]
/lib64/libc.so.6(clone+0x6d)[0x3c094d0fbd]

[Anonymous]

Well this took several hours to track down!

First of all I thought it might have been unclean data, then bad data in database (since the last record in the DB is the long filename for me).

_Finally_ tracked it down.

rsp.c calls pi_log which in turn calls util_vasprintf in util.c util_vasprintf has an intitial buffer size of 200, but it does do resizing as per vsnprintf(2). Well _almost_….

In my version (Debian) HAVE_VA_COPY was not set and so util.c does a memcpy of two va_lists. This is what causes the problem.

If I set HAVE_VA_COPY to true, it all works beautifully!

I’ll be submitting a patch to Debian for this (so it should also make it into ubuntu). I don’t know why configure isn’t setting it though…

[Anonymous]

well it’s not found since the sample code that configure uses doesn’t do:

#include

any configure gurus about?

[Anonymous]

Thanks for cracking this one.

I’ve manually set the configure options HAVE_VA_COPY and HAVE_VA__COPY to 1 and rebuilt the package on Fedora 7. I can confirm that this solves the problem.

I’m not a configure guru either, so any help for making a definitive fix/patch is appreciated.

[rpedde]

@mrflac wrote:

Thanks for cracking this one.

I’ve manually set the configure options HAVE_VA_COPY and HAVE_VA__COPY to 1 and rebuilt the package on Fedora 7. I can confirm that this solves the problem.

I’m not a configure guru either, so any help for making a definitive fix/patch is appreciated.

Fixed buffer sizes is the real problem, I think. I hadn’t remembered that being a fixed size buffer.

I’ll fix that on my side, too.

— Ron

[Author]

Posts