Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Le 28/04/2014 12:09, Thomas Schmitt a écrit :
Hi,
I tried with the xorriso -as mkisofs command, with no luck.
This command terminates with a SIGBUS no matter of the options I pass on
the command line.
Ouch.
I have no Debian of arch "sparc" in reach.
I may provide you access to a shell account on my machines if needed.
xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B
... ./tmp/miniiso/cd_tree/
Valgrind on Linux accuses xorriso-1.3.2 of a small memory leak
with such a run, but not of memory problems.
Sparc architecture is extremely picky about alignement. Bad alignement,
yields SIGSEGV whereas intel only do it in the less efficient way.
Seems to me that there an alignment problem with xorriso.
That would rather be a C compiler problem then.
But given the strange error message of genisoimage, this may
well be a local filesystem peculiarity which causes a chain
of bad memory access with more or less random end.
I traced the problem with debugger, here's the catch:
----------
(gdb) c
Continuing.
Breakpoint 3, compare_dirs (rr=0x1e1e60, ll=0x1e1e70) at
/home/seb/dev/cdrkit-1.1.11/genisoimage/write.c:652
652 if ((*r)->assoc && (*r)->assoc == (*l))
(gdb) p **r
$71 = {next = 0x1ea5b0, jnext = 0x0, isorec = {length = "f",
ext_attr_length = "", extent = "\000\000\000\000\000\000\000",
size = "\000\000\000\000\000\000\000", date =
"r\004\031\001;\016\b", flags = "\002", file_unit_size = "", interleave
= "",
volume_sequence_number = "\001\000\000\001", name_len = "\001",
name = '\000' <repeats 207 times>}, starting_block = 0,
size = 0, priority = 0, jreclen = 0 '\000', name = 0x1ea948 ".",
table = 0x0,
whole_name = 0x1ea958 "./tmp/miniiso/cd_tree/boot/.", filedir =
0x1e1470, parent_rec = 0x0, de_flags = 0, inode = 2498532,
dev = 64774, rr_attributes = 0x1ea980 "RR\005\001\201PX$\001mA",
rr_attr_size = 67, total_rr_attr_size = 67, got_rr_name = 0,
assoc = 0x0, hfs_ent = 0x0, hfs_off = 0, hfs_type = 0, sort = 0,
udf_file_entry_sector = 0, realsize = 0}
(gdb) p **l
$72 = {next = 0x1e9ba0, jnext = 0x0, isorec = {length = "f",
ext_attr_length = "", extent = "\000\000\000\000\000\000\000",
size = "\000\000\000\000\000\000\000", date =
"r\004\031\001;\016\b", flags = "\002", file_unit_size = "", interleave
= "",
volume_sequence_number = "\001\000\000\001", name_len = "\001",
name = "\001", '\000' <repeats 206 times>},
starting_block = 0, size = 0, priority = 0, jreclen = 0 '\000', name
= 0x1e1548 "..", table = 0x0,
whole_name = 0x1e9f10 "./tmp/miniiso/cd_tree/boot/..", filedir =
0x1e1470, parent_rec = 0x0, de_flags = 0, inode = 2498510,
dev = 64774, rr_attributes = 0x1e9f38 "RR\005\001\201PX$\001mA",
rr_attr_size = 67, total_rr_attr_size = 67, got_rr_name = 0,
assoc = 0x0, hfs_ent = 0x0, hfs_off = 0, hfs_type = 0, sort = 0,
udf_file_entry_sector = 0, realsize = 0}
(gdb) n
654 if ((*l)->assoc && (*l)->assoc == (*r))
(gdb)
644 rpnt = (*r)->isorec.name;
(gdb)
645 lpnt = (*l)->isorec.name;
(gdb) x rpnt
0x1ea7f9: 0x00000000
(gdb) x lpnt
0x1e9dc1: 0x01000000
(gdb) n
659 if (strcmp(rpnt, lpnt) == 0) {
(gdb) n
661 errmsgno(EX_BAD,
----------
So, strcmp shouldn't have yielded 0 when comparing the strings.
3- Fix the xorriso for alignment problem
I would love to get this done.
Can you get me a stack trace ?
Can you run it with valgrind and send me the message output ?
Hum, unfortunately, valgrind is not available for sparc.
If the failing machine is not the one which compiled xorriso
from the libisoburn source package, can you try with
wget http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz
tar xzf xorriso-1.3.2.tar.gz
cd xorriso-1.3.2 && ./configure && make
abs_path=$(pwd)
Without need for superuser or installation try:
cd ...where.appropriate...
"$abs_path"/xorriso/xorriso -as mkisofs ...above.options...
xorriso is the one compiled from isoburn. I tried with the one from the
archive, and the one rebuild from source with a debbuild.
Same problem on both.
I'm compiling at this moment the vanilla xorriso from gnu. Let's see
what it yields.
Have a nice day :)
Thomas
Thanks, you too.
Seb
Reply to: