genisoimage: HFS generation crashes on certain tree sizes

[Colin Watson]

The debian-installer build on powerpc is currently crashing due to memory corruption in genisoimage:

  http://launchpadlibrarian.net/33722076/buildlog_ubuntu-karmic-powerpc.debian-installer_20081029ubuntu68_FAILEDTOBUILD.txt.gz

genisoimage -r -T --netatalk -hfs -probe -map boot/powerpc/hfs.map -part -no-desktop -hfs-bless ./tmp/powerpc64_netboot/cd_tree/install -hfs-volid Debian-Installer/PPC -o ./tmp/powerpc64_netboot/mini.iso ./tmp/powerpc64_netboot/cd_tree
genisoimage: Warning: assuming PC Exchange cluster size of 512 bytes
Blessing install (./tmp/powerpc64_netboot/cd_tree/install)
*** glibc detected *** genisoimage: free(): invalid next size (normal): 0x101e1b18 ***
======= Backtrace: =========
/lib/libc.so.6[0xfe858b4]
/lib/libc.so.6(cfree+0x8c)[0xfe8a98c]
genisoimage(v_destruct+0x24)[0x100446c4]
genisoimage(hfs_umount+0x10c)[0x100403dc]
genisoimage(make_mac_volume+0x210)[0x10029ec0]
genisoimage[0x1002c4bc]
genisoimage(main+0x2254)[0x1000d264]
/lib/libc.so.6[0xfe2259c]
/lib/libc.so.6[0xfe22760]
======= Memory map: ========
00100000-00103000 r-xp 00100000 00:00 0
0fd74000-0fd77000 r-xp 00000000 09:00 12920599 /lib/libdl-2.10.1.so
0fd77000-0fd86000 ---p 00003000 09:00 12920599 /lib/libdl-2.10.1.so
0fd86000-0fd87000 r--p 00002000 09:00 12920599 /lib/libdl-2.10.1.so
0fd87000-0fd88000 rw-p 00003000 09:00 12920599 /lib/libdl-2.10.1.so
0fd98000-0fdaa000 r-xp 00000000 09:00 12920770 /lib/libbz2.so.1.0.4
0fdaa000-0fdba000 ---p 00012000 09:00 12920770 /lib/libbz2.so.1.0.4
0fdba000-0fdbb000 r--p 00012000 09:00 12920770 /lib/libbz2.so.1.0.4
0fdbb000-0fdbc000 rw-p 00013000 09:00 12920770 /lib/libbz2.so.1.0.4
0fdcc000-0fde2000 r-xp 00000000 09:00 12920767 /lib/libz.so.1.2.3.3
0fde2000-0fdf1000 ---p 00016000 09:00 12920767 /lib/libz.so.1.2.3.3
0fdf1000-0fdf2000 r--p 00015000 09:00 12920767 /lib/libz.so.1.2.3.3
0fdf2000-0fdf3000 rw-p 00016000 09:00 12920767 /lib/libz.so.1.2.3.3
0fe03000-0ff6d000 r-xp 00000000 09:00 12920596 /lib/libc-2.10.1.so
0ff6d000-0ff7d000 ---p 0016a000 09:00 12920596 /lib/libc-2.10.1.so
0ff7d000-0ff81000 r--p 0016a000 09:00 12920596 /lib/libc-2.10.1.so
0ff81000-0ff82000 rw-p 0016e000 09:00 12920596 /lib/libc-2.10.1.so
0ff82000-0ff85000 rw-p 0ff82000 00:00 0
0ff95000-0ffb3000 r-xp 00000000 09:00 12874666 /usr/lib/libmagic.so.1.0.0
0ffb3000-0ffc3000 ---p 0001e000 09:00 12874666 /usr/lib/libmagic.so.1.0.0
0ffc3000-0ffc4000 r--p 0001e000 09:00 12874666 /usr/lib/libmagic.so.1.0.0
0ffc4000-0ffc5000 rw-p 0001f000 09:00 12874666 /usr/lib/libmagic.so.1.0.0
0ffd5000-0ffdf000 r-xp 00000000 09:00 12887764 /usr/lib/libfakeroot/libfakeroot-sysv.so
0ffdf000-0ffee000 ---p 0000a000 09:00 12887764 /usr/lib/libfakeroot/libfakeroot-sysv.so
0ffee000-0ffef000 r--p 00009000 09:00 12887764 /usr/lib/libfakeroot/libfakeroot-sysv.so
0ffef000-0fff0000 rw-p 0000a000 09:00 12887764 /usr/lib/libfakeroot/libfakeroot-sysv.so
10000000-10070000 r-xp 00000000 09:00 12875137 /usr/bin/genisoimage
1007f000-10080000 r--p 0006f000 09:00 12875137 /usr/bin/genisoimage
10080000-1009c000 rw-p 00070000 09:00 12875137 /usr/bin/genisoimage
1009c000-101f2000 rwxp 1009c000 00:00 0 [heap]
40000000-4001f000 r-xp 00000000 09:00 12920593 /lib/ld-2.10.1.so
4001f000-40021000 rw-p 4001f000 00:00 0
40023000-40026000 rw-p 40023000 00:00 0
4002f000-40030000 r--p 0001f000 09:00 12920593 /lib/ld-2.10.1.so
40030000-40031000 rw-p 00020000 09:00 12920593 /lib/ld-2.10.1.so
40031000-4023e000 rw-p 40031000 00:00 0
40300000-40321000 rw-p 40300000 00:00 0
40321000-40400000 ---p 40321000 00:00 0
ffc6b000-ffc80000 rw-p ffc6b000 00:00 0 [stack]

I've dug into this a bit, and it appears to be related to the size of the tree being built. I've attached a tarball of the tree in question (warning: 12MB) which can be used to reproduce this bug. I *think* that it has something to do with drNmAlBlks being initialised to (vlen - 5 - vbmsz) / lpa in XClpSiz, but a similar offset not being applied in hfs_umount, but I really don't know HFS well enough to attempt a fix.

A ghastly workaround in debian-installer is to create a padding file of at least 512*5 bytes, to get past the boundary region, and since we're in the 9.10 release crunch at the moment I'm going to go ahead with this rather than risk creating further bugs by changing genisoimage right now.

[Schily (schilling-fokus)]

You are not using original software but a buggy and legally undistributable
fork that has been created by a hostile downstream.

If you look at the bug tracking system of the various Linux distributors that
do not distribute the original software, you will find more than 100 bugs
that are specific to the fork. For this reason, it is always a good idea to
check the original software in case of problems. I am sure that your
problem will go away if you upgrade to recent original software from:

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

http://cdrecord.berlios.de/

The original software has the advantage that there are no known
bugs, that there are no legal problems and that there are a lot
of new features that are missing in the fork that was created from
a more than 4 year old original software.