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
