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 -- 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
