icedax dies with buffer overflow

[ilf]

Binary package hint: icedax

On an up-to-date Karmic, running abcde 2.3.99.7-1ubuntu1, which calls icedax 9:1.1.9-1ubuntu1, I get this error:

*** buffer overflow detected ***: cdda2wav terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x7ffe1e7aa5f7]
/lib/libc.so.6[0x7ffe1e7a95a0]
/lib/libc.so.6[0x7ffe1e7a8a09]
/lib/libc.so.6(_IO_default_xsputn+0x98)[0x7ffe1e727448]
/lib/libc.so.6(_IO_vfprintf+0x18aa)[0x7ffe1e6f964a]
/lib/libc.so.6(__vsprintf_chk+0x99)[0x7ffe1e7a8aa9]
/lib/libc.so.6(__sprintf_chk+0x7f)[0x7ffe1e7a89ef]
cdda2wav(calc_cdindex_id+0xf2)[0x41ca82]
cdda2wav(main+0x1107)[0x40ceb7]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7ffe1e6d1abd]
cdda2wav[0x409239]
======= Memory map: ========
00400000-0044c000 r-xp 00000000 fc:01 138036 /usr/bin/icedax
0064b000-0064c000 r--p 0004b000 fc:01 138036 /usr/bin/icedax
0064c000-0064e000 rw-p 0004c000 fc:01 138036 /usr/bin/icedax
0064e000-00651000 rw-p 00000000 00:00 0
00b33000-00cde000 rw-p 00000000 00:00 0 [heap]
7ffe1e498000-7ffe1e4b2000 r-xp 00000000 fc:01 138135 /lib/libgcc_s.so.1
7ffe1e4b2000-7ffe1e6b1000 ---p 0001a000 fc:01 138135 /lib/libgcc_s.so.1
7ffe1e6b1000-7ffe1e6b2000 r--p 00019000 fc:01 138135 /lib/libgcc_s.so.1
7ffe1e6b2000-7ffe1e6b3000 rw-p 0001a000 fc:01 138135 /lib/libgcc_s.so.1
7ffe1e6b3000-7ffe1e819000 r-xp 00000000 fc:01 138402 /lib/libc-2.10.1.so
7ffe1e819000-7ffe1ea18000 ---p 00166000 fc:01 138402 /lib/libc-2.10.1.so
7ffe1ea18000-7ffe1ea1c000 r--p 00165000 fc:01 138402 /lib/libc-2.10.1.so
7ffe1ea1c000-7ffe1ea1d000 rw-p 00169000 fc:01 138402 /lib/libc-2.10.1.so
7ffe1ea1d000-7ffe1ea22000 rw-p 00000000 00:00 0
7ffe1ea22000-7ffe1ea41000 r-xp 00000000 fc:01 132623 /lib/ld-2.10.1.so
7ffe1ec07000-7ffe1ec27000 rw-s 00000000 00:09 1301285 /dev/zero (deleted)
7ffe1ec27000-7ffe1ec29000 rw-p 00000000 00:00 0
7ffe1ec3d000-7ffe1ec40000 rw-p 00000000 00:00 0
7ffe1ec40000-7ffe1ec41000 r--p 0001e000 fc:01 132623 /lib/ld-2.10.1.so
7ffe1ec41000-7ffe1ec42000 rw-p 0001f000 fc:01 132623 /lib/ld-2.10.1.so
7fff08c1f000-7fff08c34000 rw-p 00000000 00:00 0 [stack]
7fff08dff000-7fff08e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
/usr/bin/abcde: line 2751: 4375 Aborted nice $READNICE $CDROMREADER -D $CDDA2WAVCDROM -t ${READTRACKNUMS:-$UTRACKNUM} "$FILEARG" $REDIR
[ERROR] abcde: The following commands failed to run:
readtrack-02: cdda2wav returned code 134
Finished. Not cleaning /tmp/abcde.15124c13.

[Schily (schilling-fokus)]

"icedax" is a fork from an extremely old cdda2wav version (aprox, 5 Years old).

The original software meanwhile has undergone massive bug fixes and
development. Try ti replace "cdrkit" by recent original software:

ftp://ftp.berlios.de/pub/cdrecord/alpha/
http://cdrecord.berlios.de/

and test again.

[ilf (ilf)]

I tried installing cdda2wav from cdrtools-2.01.01. But it fails:

/usr/local/src/cdrtools-2.01.01/cdda2wav$ sudo make
../RULES/rules.top:43: ../RULES/ldummy.lnk: No such file or directory
                W A R N I N G Messages like:

gmake[2]: Entering directory `/tmp/cdrtools-2.01/libschily'
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/cvmod.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/dat.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/fcons.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/fdown.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/fdup.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/ffileread.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/ffilewrite.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/fgetline.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/fgetstr.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/file_raise.d: No such file or directory
../RULES/r-gmake.dep:76: OBJ/<arch-dir>/fileclose.d: No such file or directory
....

are caused by a GNU make bug and not by the Schily makefile system.

The related bug has been reported to the GNU make maintainers in 1998 but
as the bug has not yet been fixed, it seems that GNU make is unmaintained :-(
A working highly portable make program is at ftp://ftp.berlios.de/pub/smake

You may switch off this warning by calling "gmake GMAKE_NOWARN=true ..."
../RULES/rules1.top:250: ../incs/Dnull: No such file or directory
../RULES/rules1.top:257: ../incs/Dcc.x86_64-linux: No such file or directory
../RULES/rules.top:70: ../RULES/x86_64-linux-cc.rul: No such file or directory
../RULES/rules.cnf:66: ../incs/x86_64-linux-cc/Inull: No such file or directory
../RULES/rules.cnf:67: ../incs/x86_64-linux-cc/rules.cnf: No such file or directory
../RULES/local.cnf:43: OBJ/x86_64-linux-cc/Inull: No such file or directory
../RULES/local.cnf:44: OBJ/x86_64-linux-cc/local.cnf: No such file or directory
../RULES/rules.obj:23: ../RULES/r-gmake.obj: No such file or directory
make: *** No rule to make target `../RULES/r-gmake.obj'. Stop.

Anyways, there seems to be some kind of dispute between cdda2wav and icedax, cdrkit and cdrtools, upstream authors and package maintainers. I really don't have the time to dig into this. I'd just like to get this Bug fixed.

If switching to cdrecord solves this and is the right solution, then the package maintainers should switch. I personally don't care whether that would happen in Debian or Ubuntu or whereever.

[Schily (schilling-fokus)]

You are using an outdated version of gmake that has bugs that completely
prevent compilation.

If you like to use gmake instead of smake, you need to use at least gmake-3.81

Older gmake versions completely ignore some make rules and this is what happened
for you.

BTW: the "problem" you mention is a social problem that was initiated by a hostile
packaging maintainer from Debian who attacked the project, see:

http://cdrecord.berlios.de/private/linux-dist.html

for more information The OSS community unfortunately does not yet have a method
to deal with hostile downstreams.

If you like to get Ubuntu packages for the legal and working original software
instead of the buggy and undistributable fork, you would need to contact Ubuntu
and ask Ubuntu for fixing it's fault.

I cannot understand why Ubuntu still distributes the unmaintained fork...

[ilf (ilf)]

I am using the current GNU Make 3.81 in Ubuntu packaged flavor 3.81-6, so the problem seems to be on your smake "optimization". There's no smake package.

That's the problem description from your side, the other side is here: http://lists.debian.org/debian-devel-announce/2006/09/msg00002.html

I personally don't care, I'd just like my packages to work. That's why I'm filing a Bug against the package, not against upstream.

[Schily (schilling-fokus)]

Then I cannot help you as cdrtools compile just fine for me on an Ubuntu system
using gmake-3.81.

As your gmake did complain about a file RULES/r-gmake.obj that definitely is part
of the tarball, your problem may be caused by a bug un GNU tar. GNU tar is known
for not being very reliable, did you alternatively "star" to unpack?

BTW: you did quote a statement from the hostile person (Eduard Bloch) who did
start the conflict by attacking the project. If you carefully read what you quoted, you will
see that it is full of offensive words and e.g. attacks the biggest OSS source (Sun Microsystems).
I hope this helps to judge on the credibility of this text.....

[ilf (ilf)]

Jörg, RULES/r-gmake.obj is in none of cdrtools-beta.tar.gz, cdrtools-2.01.01a65.tar.gz or cdrtools-2.01.01a65.tar.bz2.
Yes, I am using GNU tar 1.22. No, I do not want star or smake. I'm on Ubuntu, not Jörg Schilling Solaris.

I'm starting to want a fix in icedax.

[Schily (schilling-fokus)]

Sorry for my fault, r-gmake.obj is a symlink to r-make.obj that is automatically
created by RULES/MKLINKS and this script is called automatically by a non-broken
make program. Did you try to run gmake asecond time? Sometimes the bugs in gmake
let gmake abort although it did run the right commands.....

And sorry, icedax is broken unmaintained and illegal.

[ilf (ilf)]

Yes, I tried running it a second time and it didn't work.
I even tried creating the symlink by hand, then I get the next error:

parse.c: In function 'pabort':
parse.c:484: warning: unknown conversion type character 'r' in format
parse.c:484: warning: format '%d' expects type 'int', but argument 3 has type 'const char *'
parse.c:484: warning: format '%s' expects type 'char *', but argument 4 has type 'struct __va_list_tag *'
        ==> LINKING "OBJ/x86_64-linux-cc/cdda2wav"
/usr/bin/ld: cannot find -lscgcmd
collect2: ld returned 1 exit status
make: *** [OBJ/x86_64-linux-cc/cdda2wav] Error 1

[Schily (schilling-fokus)]

Your problem is unfortunately also a bug in the shell (/bin/sh)
that causes the make process not to abort on errors :-(

Plase send the error message from compiling libscgcmd

[ilf (ilf)]

I don't want to compile libscgcmd, I wanted cdda2wav.

[Schily (schilling-fokus)]

cdda2wav depends on libscgcmd that is therefore part of the cdrtools
source tarball.

Your problem is that you use an old buggy bash as /bin/sh and GNU make
to compile so as a result of the buggy software, your compilation does not abort
when it encounters compile problems.

In order to find the other reasons for your problems, I need the error messages from compiling libscgcmd

[ilf (ilf)]

I am not using bash as /bin/sh. libscgcmd compiles fine.

I don't want to be told that my POSIX-Shell, GNU make and GNU tar are buggy and cdrkit is illegal.
And I don't want to be instrumentalized in this onging fight by you.

I just want icedax to get fixed in Ubuntu.
If your cdda2wav fixes it, talk to the Debian and Ubuntu maintainers to either merge your Bugfix for this error or switch to your cdrecord again. But please leave me out of it.

[Schily (schilling-fokus)]

if you believe that libscgcmd compiled fine, why then do you tell me that
cdda2wav does not find it for linking?

[ilf (ilf)]

Because I still geth the same error compiling cdda2wav while libscgcmd compiled without an error (just warnings).

[Schily (schilling-fokus)]

then you did not compile libscgcmd for some reasons or your make program does
not work correctly.

If libscgcmd compiled, there is a lib that cdda2wav can link against.....

[Schily (schilling-fokus)]

BTW: just a note... as your problems seem to be caused by the fact that
the variant of GNU make you ar using does not work properly, I recommend you
to fetch a recent schily source _bundle_ version from:

ftp://ftp.berlios.de/pub/schily/

This contains all OSS I publish including smake.
if cou call GNU make at top level, this will wirst build smake using a shell
script and then use this bootstrap smake to compile the rest. As smake is
known to have less problems than GNU make, this will help you.....