On 11/25/2010 02:06 AM, Thomas Egerer wrote: > I've encountered the same problem on a non-AMD64 machine. > It's quite obvious why the application crashes, because glibc abort()s due to > failed fortification checks. From my experience ripperX reproducibly crashes > when finishing an mp3 with a track number > 9 (I ripped a number of CDs and > ripperX gave me all tracks encoded and properly named, but without ID3-tag > for all those >= 10]). While examining the problem I stumbled across this > thread and -- even though fractal13's patch works -- I'd propose a different > solution. > a) using dynamically allocated memory *is* overkill. And even if it has > little to none performance impact in this case, if all bugs would be fixed > like this, I'd still be sitting here watching my box boot instead of writing > this. > b) according to red book standard (available for $300 or so :() the number of > tracks on a compact disc is limited to 99 (ever wondered why your CD player > has a two-digit display only?), so a static char buffer of size 3 is > sufficient. If you use snprintf to limit the number of characters you're fine. > So please refrain from 'spoiling' my favourite mp3-encoder by using malloc to > fix this bug. > > ** Patch added: "revised patch for this bug not using malloc" > > https://bugs.launchpad.net/ubuntu/+source/ripperx/+bug/514739/+attachment/1744481/+files/fix_2_digit_track_numbers.diff >
Hi Thomas, Thank you for your post and the patch. Just to be clear, you are still experiencing crashes with the latest upstream release of ripperX, 2.7.3? Thank you, tony -- ripperX assert failure: *** buffer overflow detected ***: ripperx terminated https://bugs.launchpad.net/bugs/514739 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
