You are here: Home » Topic » Crash with long file names

Crash with long file names

This topic contains 4 replies, has 3 voices, and was last updated by  rpedde 9 years, 11 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #2099

    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]

    #15715

    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…

    #15716

    Anonymous

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

    #include

    any configure gurus about?

    #15717

    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.

    #15718

    rpedde
    Participant

    @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

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.