Patches in comments 6 and 9 are in 2.7.3-1 in natty. We need to fix this
in lucid and maverick.
** Also affects: ripperx (Ubuntu Lucid)
Importance: Undecided
Status: New
** Also affects: ripperx (Ubuntu Maverick)
Importance: Undecided
Status: New
** Changed in: ripperx
On 11/27/2010 09:02 AM, Thomas Egerer wrote:
Hi Tony,
the upstream HEAD revision is not affected by this problem any more. Plus: I
had to amend my patch, I overlooked the free statement to s_track_num.
To be honest, I didn't check the svn repo before posting here. The bug is
still new
Hi Tony,
the upstream HEAD revision is not affected by this problem any more. Plus: I
had to amend my patch, I overlooked the free statement to s_track_num.
To be honest, I didn't check the svn repo before posting here. The bug is still
new while the fix is already applied to the upstream repo.
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
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
I rebuilt ripperX from the source packages and the error returned on my
system. This would seem to be good evidence that the patch is useful.
I also have used ripperX for many years. That's why I was motivated to
find a solution to the problem when I moved to lucid. However, just
because the
** Tags added: patch
--
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
Here's another buffer overflow bug fix. To see this problem, you have
to encode many tracks without restarting ripperX. The path environment
variable outgrows the buffer size in this function.
** Patch added: fix_path_buffer_overflow.diff
This problem is not caused by libid3tag. RipperX has an array of size 2
to store the track number string into. So, higher than 1 digits, plus
the null character cause the buffer to overflow. I imagine other builds
do not have problems because they are lucky with stack frame
construction.
On 11/05/2010 09:48 PM, fractal13 wrote:
This problem is not caused by libid3tag. RipperX has an array of size 2
to store the track number string into. So, higher than 1 digits, plus
the null character cause the buffer to overflow. I imagine other builds
do not have problems because they
This is actually as far as I know a bug in libid3tag library. It happens
if trying to tag a track with track number of over 9. Apparently it only
affects mp3s that are encoded with VBR. As such, the bug also affects
every other program using id3tag library.
See here for more on this:
** Attachment added: CoreDump.gz
http://launchpadlibrarian.net/38555447/CoreDump.gz
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/38555448/Dependencies.txt
** Attachment added: Disassembly.txt
http://launchpadlibrarian.net/38555449/Disassembly.txt
** Attachment
12 matches
Mail list logo
