Debian Bug report logs - #731806
debian-installer: FTBFS on sparc: genisoimage errors

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 09 Dec 2013 23:44:18 +0100

Source: debian-installer
Version: 20131014
Severity: serious
Justification: FTBFS

Hi people,

(-sparc, -cd, genisoimage maintainers x-d-cc'd)

debian-installer 20131014 FTBFS'd on the buildd with:
| […]
| install -m 644 ./tmp/miniiso/boot_screens/notsupported.txt ./tmp/miniiso/cd_tree/boot
| install -m 644 boot/sparc/silo.conf ./tmp/miniiso/cd_tree/boot
| genisoimage -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B ... ./tmp/miniiso/cd_tree
| genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and './tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.
| Unable to sort directory ./tmp/miniiso/cd_tree/boot

Full build log:
  https://buildd.debian.org/status/fetch.php?pkg=debian-installer&arch=sparc&ver=20131014&stamp=1381835153

I can't tell for sure since it's been a while but I think I was unable
to reproduce it on a porterbox. Probably some FS-dependent fun? Anyone
would have a clue about it?

Thanks for your time.

Mraw,
KiBi.

Message #10 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 10 Dec 2013 08:38:32 +0100

Hi,

Cyril Brulebois wrote:
> genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and
> './tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.
> [...]
> Probably some FS-dependent fun? Anyone would have a clue about it?

Looks like an internal error of genisoimage.

'.' should be mapped to a 0x00-byte in ECMA-119, '..' to 0x01.
See ECMA-119, 6.8.2.2 Identification of directories.
These names are reserved for that purpose.
Any other colliding ECMA-119 names should be handled by mangling.


But why is that mini.iso produced by genisoimage at all ?
debian-7.2.0-sparc-netinst.iso was produced by xorriso.


Have a nice day :)

Thomas

Message #15 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: sparc@buildd.debian.org, debian-release@lists.debian.org, ftpmaster@debian.org

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Thu, 13 Feb 2014 16:38:36 +0300

[Message part 1 (text/plain, inline)]

[ TL;DR: d-i FTBFS on sparc, what do we do now? ]

Thomas Schmitt <scdbackup@gmx.net> (2013-12-10):
> Cyril Brulebois wrote:
> > genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and
> > './tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.
> > [...]
> > Probably some FS-dependent fun? Anyone would have a clue about it?
> 
> Looks like an internal error of genisoimage.
> 
> '.' should be mapped to a 0x00-byte in ECMA-119, '..' to 0x01.
> See ECMA-119, 6.8.2.2 Identification of directories.
> These names are reserved for that purpose.
> Any other colliding ECMA-119 names should be handled by mangling.

Thanks, Thomas.


@Kurt: did anything change on the buildd setup side? Both lebrun and spontini
got that FTBFS, while that wasn't the case before:
  https://buildd.debian.org/status/logs.php?pkg=debian-installer&arch=sparc

genisoimage comes from src:cdrkit, which wasn't exactly updated in a while:
  http://packages.qa.debian.org/c/cdrkit.html

I've got to double check what happens on smetana, but I think I didn't
get that error when trying to debug this FTBFS a few months ago.

I'm not sure we want to continuously give it back until it builds (which
it might on schroeder, since it didn't fail there yet)…


Failing a short resolution, I'm tempted to pretend sparc isn't an issue,
and maybe ask for a migration to testing + dak copy-installer.

@debian-release: would that sound reasonable?

@ftpmasters: I'm not sure an out-of-date build is going to be OK on the
dak side. What do you think?


> But why is that mini.iso produced by genisoimage at all ?
> debian-7.2.0-sparc-netinst.iso was produced by xorriso.

@Thomas: Probably due to historical reasons. Not sure I want to be
touching that since I know nothing about architecture/image-specific
settings. :/

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: kibi@debian.org

Cc: 731806@bugs.debian.org,ftpmaster@debian.org,debian-release@lists.debian.org,sparc@buildd.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Thu, 13 Feb 2014 15:27:31 +0100

Hi,

> I'm not sure we want to continuously give it back until it builds (which
> it might on schroeder, since it didn't fail there yet)...

I would assume the problem is deterministic and depends on
the exact tree of file names which is given to genisoimage
as input.
So adding a few names of empty files here and there might help.


> > But why is that mini.iso produced by genisoimage at all ?
> > debian-7.2.0-sparc-netinst.iso was produced by xorriso.

> @Thomas: Probably due to historical reasons. Not sure I want to be
> touching that since I know nothing about architecture/image-specific
> settings. :/

Debian-cd uses xorriso's compatibility command "-as mkisofs".
If you have the opportunity to just exchange every occurence of
   genisoimage
by
   xorriso -as mkisofs
or, if a single word is needed, by its symbolic link alias
   xorrisofs
then this might well be worth a try.

It should work with xorriso-1.3.2 from sid, and most probably
also with 1.2.2 from stable. debian-7.4.0-sparc-netinst.iso was
built by xorriso-1.2.6, probably from
  http://www.gnu.org/software/xorriso/xorriso-1.2.6.tar.gz


If you can point me to the code which controls the genisoimage
run, then i will inspect it for problematic options.


Have a nice day :)

Thomas

Message #25 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: sparc@buildd.debian.org, debian-release@lists.debian.org, ftpmaster@debian.org

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 25 Feb 2014 19:56:02 +0300

[Message part 1 (text/plain, inline)]

Cyril Brulebois <kibi@debian.org> (2014-02-13):
> [ TL;DR: d-i FTBFS on sparc, what do we do now? ]
> 
> @Kurt: did anything change on the buildd setup side? Both lebrun and spontini
> got that FTBFS, while that wasn't the case before:
>   https://buildd.debian.org/status/logs.php?pkg=debian-installer&arch=sparc

Ping?

> Failing a short resolution, I'm tempted to pretend sparc isn't an issue,
> and maybe ask for a migration to testing + dak copy-installer.
> 
> @debian-release: would that sound reasonable?

Ping?

> @ftpmasters: I'm not sure an out-of-date build is going to be OK on the
> dak side. What do you think?

Ping?


Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Cyril Brulebois <kibi@debian.org>

Cc: sparc@buildd.debian.org, debian-release@lists.debian.org, ftpmaster@debian.org, Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 25 Feb 2014 18:54:31 +0100

On Thu, Feb 13, 2014 at 04:38:36PM +0300, Cyril Brulebois wrote:
> [ TL;DR: d-i FTBFS on sparc, what do we do now? ]
> 
> Thomas Schmitt <scdbackup@gmx.net> (2013-12-10):
> > Cyril Brulebois wrote:
> > > genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and
> > > './tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.
> > > [...]
> > > Probably some FS-dependent fun? Anyone would have a clue about it?
> > 
> > Looks like an internal error of genisoimage.
> > 
> > '.' should be mapped to a 0x00-byte in ECMA-119, '..' to 0x01.
> > See ECMA-119, 6.8.2.2 Identification of directories.
> > These names are reserved for that purpose.
> > Any other colliding ECMA-119 names should be handled by mangling.
> 
> Thanks, Thomas.
> 
> 
> @Kurt: did anything change on the buildd setup side? Both lebrun and spontini
> got that FTBFS, while that wasn't the case before:
>   https://buildd.debian.org/status/logs.php?pkg=debian-installer&arch=sparc

Nothing changed recently.  They've been using tar based chroots
for at least 6 months I think.


Kurt

Message #35 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Cyril Brulebois <kibi@debian.org>

Cc: sparc@buildd.debian.org, debian-release@lists.debian.org, ftpmaster@debian.org, Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 25 Feb 2014 20:40:12 +0100

On 2014-02-25 17:56, Cyril Brulebois wrote:
> Cyril Brulebois <kibi@debian.org> (2014-02-13):
>> [...]
>> Failing a short resolution, I'm tempted to pretend sparc isn't an issue,
>> and maybe ask for a migration to testing + dak copy-installer.
>>
>> @debian-release: would that sound reasonable?
> 
> Ping?
> 
> [...]
> 
> 
> Mraw,
> KiBi.
> 


To my knowledge, there has been no visible attempt to keep sparc alive
in testing and, indeed, no sparc porters objecting to this suggestion.
Based on that, I would say it sounds entirely reasonable to ignore sparc.

~Niels

Message #42 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: debian-sparc@lists.debian.org, 731806@bugs.debian.org

Subject: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 10:52:21 +0200

I've been looking through this problem.

genisoimage is reporting a problem with . and .. aliased to the same '' 
name.
logs of the problem:
-------------
genisoimage -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B ... 
./tmp/miniiso/cd_tree
I: -input-charset not specified, using utf-8 (detected in locale settings)
genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and 
'./tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.
Unable to sort directory ./tmp/miniiso/cd_tree/boot
-------------

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.
Seems to me that there an alignment problem with xorriso.
Here's the log associated
-------------
xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B 
... ./tmp/miniiso/cd_tree/
xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:./tmp/miniiso/mini.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 9163m free
Added to ISO image: directory 
'/'='/home/seb/dev/debian-installer-20140316/build/tmp/miniiso/cd_tree'
xorriso : UPDATE : 7 files added in 1 seconds
xorriso : UPDATE : 7 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 7040 bytes from file 
'/boot/isofs.b'

UNIX-SIGNAL: SIGBUS errno= 13
xorriso : ABORT : Trying to shut down busy drives
xorriso : ABORT : Wait the normal burning time before any kill -9
bus error
-------------

Finally, I downloaded the cdrtools from berlios, and rebuild a mkisofs 
from source.
With this mkisofs, the build of the iso went without a problem, so I'm 
thinking this problem seems to be a bug in the genisoimage.
Here's the log:
-------------
../../cdrtools-3.01/mkisofs/OBJ/sparc64-linux-cc/mkisofs -r -J -o 
./tmp/miniiso/mini.iso -G /boot/isofs.b -B ... ./tmp/miniiso/cd_tree/
Setting input-charset to 'UTF-8' from locale.
Total translation table size: 0
Total rockridge attributes bytes: 966
Total directory bytes: 2048
Path table size(bytes): 22
Total extents including sparc boot = 4160
Max brk space used 0
4310 extents written (8 MB)
-------------

So, this does not seems to be related to sparc, but rather to genisoimage.
There 3 ways possibles to fix this in increasing workload :
1- Create a package for mkisofs original which works ok to generate this 
iso.
2- Fix the genisoimage
3- Fix the xorriso for alignment problem

I'll have a look at the genisoimage.

My 0,02€ contribution.

S. Bernard

Message #47 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Cc: <sbernard@nerim.net>, <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 12:09:41 +0200

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.


> 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.


> 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.


> 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 ?

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...


Have a nice day :)

Thomas

Message #52 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Cc: sbernard@nerim.net, debian-sparc@lists.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 12:29:06 +0200

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

Message #57 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Cc: <sbernard@nerim.net>, <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 13:20:20 +0200

Hi,

> I may provide you access to a shell account on my machines if needed.

Yes, please.

Plus a directory tree
  ./tmp/miniiso/cd_tree
which can cause the xorriso crash.


> Sparc architecture is extremely picky about alignement. Bad alignement,
> yields SIGSEGV whereas intel only do it in the less efficient way.

I would suspect the habit of my libisofs predecessor developer
to use structs as access frame for byte arrays read from file.

But why then was it possible to produce
  debian-7.4.0-sparc-netinst.iso
by xorriso-1.2.6 as can be read from its "Preparer Id":
  XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, LIBBURN-1.2.6
Does debian-cd pull "sparc" trees onto a non-sparc machine ?


> [genisoimage]
> (gdb) x rpnt
> 0x1ea7f9:    0x00000000
> (gdb) x lpnt
> 0x1e9dc1:    0x01000000
> (gdb) n
> 659        if (strcmp(rpnt, lpnt) == 0) {

Both values match the prescribed names for "." and ".." in ECMA-119
(aka ISO 9660), 6.8.2.2 Identification of directories:
Single byte 0x00 is ".", single byte 0x01 is "..".

> So, strcmp shouldn't have yielded 0 when comparing the strings.

Can this be caused by alignment problems ?


> Hum, unfortunately, valgrind is not available for sparc.

Then gdb will have to do.


> 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.

If you also built libisofs and libburn from source, then this burries
my theory of a binary incompatibility between two SPARC machines.

> I'm compiling at this moment the vanilla xorriso from gnu.
> Let's see what it yields.

It has the same source as the three library tarballs used as input
for Debian's xorriso. Only difference is that GNU xorriso brings
own copies of the library source code and links it statically with
the xorriso main program.
So it can be easily tested without interfering with installations
of the libraries. (And with no need for superuser privileges.)


Have a nice day :)

Thomas

Message #62 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Cc: debian-sparc@lists.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 13:35:18 +0200

Le 28/04/2014 13:20, Thomas Schmitt a écrit :
>
>> [genisoimage]
>> (gdb) x rpnt
>> 0x1ea7f9:    0x00000000
>> (gdb) x lpnt
>> 0x1e9dc1:    0x01000000
>> (gdb) n
>> 659        if (strcmp(rpnt, lpnt) == 0) {
> Both values match the prescribed names for "." and ".." in ECMA-119
> (aka ISO 9660), 6.8.2.2 Identification of directories:
> Single byte 0x00 is ".", single byte 0x01 is "..".
Ok, I got the bug nailed.
Here's a sample session from my sparc:
----------
cat  test_strcmp.c<<EOF
#include <stdio.h>
#include <stdlib.h>

void main(void) {
  char stra[2];
  char strb[2];
  int result = 0;

  stra[0] = 0;
  stra[1] = 0;
  strb[0] = 1;
  strb[1] = 0;

  result = strcmp(stra,strb);

  printf("result from strcmp('\\0000','\\0001' is %d)\n",result);
  exit(0);
}
EOF
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\0000','\0001' is 0)
----------

Here's the same sample from my intel workstation:
----------
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\0000','\0001' is -1)
----------

Typicaly, an endianness error.

If I apply this patch on cdrkit:
--- genisoimage/write.c    2014-04-28 13:31:28.103571175 +0200
+++ genisoimage/write.c.new    2014-04-28 13:31:07.255433923 +0200
@@ -656,7 +656,7 @@
 #endif    /* APPLE_HYB */

     /* If the entries are the same, this is an error. */
-    if (strcmp(rpnt, lpnt) == 0) {
+    if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {
 #ifdef    USE_LIBSCHILY
         errmsgno(EX_BAD,
             "Error: '%s' and '%s' have the same ISO9660 name '%s'.\n",

Then the iso is correctly generated.

I'll file a bug with cdrkit. I think that genisoimage with that test is 
unable to generated any iso at all on big endian machines.
>> So, strcmp shouldn't have yielded 0 when comparing the strings.
> Can this be caused by alignment problems ?
Nope.
>
>
>> Hum, unfortunately, valgrind is not available for sparc.
> Then gdb will have to do.
>
>
>> 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.
> If you also built libisofs and libburn from source, then this burries
> my theory of a binary incompatibility between two SPARC machines.
>
>> I'm compiling at this moment the vanilla xorriso from gnu.
>> Let's see what it yields.
> It has the same source as the three library tarballs used as input
> for Debian's xorriso. Only difference is that GNU xorriso brings
> own copies of the library source code and links it statically with
> the xorriso main program.
> So it can be easily tested without interfering with installations
> of the libraries. (And with no need for superuser privileges.)
I filed a bug with xorriso. Waiting for the number to show up.
>
>
> Have a nice day :)
>
> Thomas
>
>
You too ; ).

Seb

Message #67 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Cc: sbernard@nerim.net, debian-sparc@lists.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 12:35:44 +0100

On Mon, Apr 28, 2014 at 01:20:20PM +0200, Thomas Schmitt wrote:
>Hi,
>
>> I may provide you access to a shell account on my machines if needed.
>
>Yes, please.
>
>Plus a directory tree
>  ./tmp/miniiso/cd_tree
>which can cause the xorriso crash.
>
>
>> Sparc architecture is extremely picky about alignement. Bad alignement,
>> yields SIGSEGV whereas intel only do it in the less efficient way.
>
>I would suspect the habit of my libisofs predecessor developer
>to use structs as access frame for byte arrays read from file.
>
>But why then was it possible to produce
>  debian-7.4.0-sparc-netinst.iso
>by xorriso-1.2.6 as can be read from its "Preparer Id":
>  XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, LIBBURN-1.2.6
>Does debian-cd pull "sparc" trees onto a non-sparc machine ?

Yes. We build all the release images on an amd64 machine, pettersson.d.o

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll

Message #72 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Cc: <sbernard@nerim.net>, <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 14:15:14 +0200

Hi,

Sébastien Bernard:
> result from strcmp('\0000','\0001' is 0)
> result from strcmp('\0000','\0001' is -1)
> Typicaly, an endianness error.

But one in strcmp(), not in your code or the one of genisoimage.
You compare an empty string with a string that contains one
character 0x01.
This is under no endianness allowed to strcmp() == 0.

Endianness would only be of interest if you compare characters
of more than one byte each. (I.e. sizeof(char) == 2)
But that would be quite an odd environment for a C program.
char is neither guaranteed to be signed nor to be 8 bit.
Nevertheless programs would break in large numbers if that
assumption was not fulfilled.


> -    if (strcmp(rpnt, lpnt) == 0) {
> +    if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {

Are you sure that it does not miscompare other strings too ?


> I think that genisoimage with that test is
> unable to generated any iso at all on big endian machines.

I cannot agree with this diagnosis.
Not having a big-endian machine at hand now, i can confirm from
my old SunOS-4-on-SPARC days that strcmp() is supposed to yield
a non-zero result with your example char arrays.

strcmp() may well be implemented by word comparisons. But then it
is the duty of the implementation to properly handle the ends of
the strings even if those are not word aligned.


> I filed a bug with xorriso. Waiting for the number to show up.

I will hopefully get a notification via the pkg-libburnia-devel
list. Else i will bother you.


Steve McIntyre:
> We build all the release images on an amd64 machine, pettersson.d.o

Ok. That explains why there are sparc-bootable ISOs from xorriso.



Have a nice day :)

Thomas

Message #77 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Cc: debian-sparc@lists.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 15:17:34 +0200

Le 28/04/2014 14:15, Thomas Schmitt a écrit :
> Hi,
>
> Sébastien Bernard:
>> result from strcmp('\0000','\0001' is 0)
>> result from strcmp('\0000','\0001' is -1)
>> Typicaly, an endianness error.
> But one in strcmp(), not in your code or the one of genisoimage.
> You compare an empty string with a string that contains one
> character 0x01.
> This is under no endianness allowed to strcmp() == 0.
Ok, you are correct.
strcmp yields a bad result. I wasn't sure strcmp was doing byte comparaison.
However, memcmp function is ok.


>> -    if (strcmp(rpnt, lpnt) == 0) {
>> +    if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {
> Are you sure that it does not miscompare other strings too ?
Basically, the fix is just to check, in case of strcmp() == 0 that the 
first byte of each string is the same.
It's should be redundant operation if strcmp == 0 but not in the case of 
strcmp is misbehaving.
It's just a workaround. The correct fix is, of course, to fix the strcmp.
Another workaround would be to use :

-    if (strcmp(rpnt, lpnt) == 0) {
+    if (memcmp(rpnt, lpnt,MAX_ISONAME+1) == 0) {


>
>
>> I think that genisoimage with that test is
>> unable to generated any iso at all on big endian machines.
> I cannot agree with this diagnosis.
> Not having a big-endian machine at hand now, i can confirm from
> my old SunOS-4-on-SPARC days that strcmp() is supposed to yield
> a non-zero result with your example char arrays.
>
> strcmp() may well be implemented by word comparisons. But then it
> is the duty of the implementation to properly handle the ends of
> the strings even if those are not word aligned.
Indeed, the correct fix is using strcmp. Meanwhile, the package is broken.

>
>
>> I filed a bug with xorriso. Waiting for the number to show up.
> I will hopefully get a notification via the pkg-libburnia-devel
> list. Else i will bother you.

Hum, still no answer. I'm going to fill it again.

>
>
> Steve McIntyre:
>> We build all the release images on an amd64 machine, pettersson.d.o
> Ok. That explains why there are sparc-bootable ISOs from xorriso.
I didn't imagine it could be doable.
>
>
>
> Have a nice day :)
>
> Thomas
>
>
Thanks for your time and dedication.

Seb

Message #82 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: Sébastien Bernard <sbernard@nerim.net>

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org, "debian-sparc@lists.debian.org" <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 09:05:45 -0500

[Message part 1 (text/plain, inline)]

On Mon, Apr 28, 2014 at 8:17 AM, Sébastien Bernard <sbernard@nerim.net>wrote:

> Le 28/04/2014 14:15, Thomas Schmitt a écrit :
>
>  Hi,
>>
>> Sébastien Bernard:
>>
>>> result from strcmp('\0000','\0001' is 0)
>>> result from strcmp('\0000','\0001' is -1)
>>> Typicaly, an endianness error.
>>>
>> But one in strcmp(), not in your code or the one of genisoimage.
>> You compare an empty string with a string that contains one
>> character 0x01.
>> This is under no endianness allowed to strcmp() == 0.
>>
> Ok, you are correct.
> strcmp yields a bad result. I wasn't sure strcmp was doing byte
> comparaison.
> However, memcmp function is ok.
>
>
>
>  -    if (strcmp(rpnt, lpnt) == 0) {
>>> +    if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {
>>>
>> Are you sure that it does not miscompare other strings too ?
>>
> Basically, the fix is just to check, in case of strcmp() == 0 that the
> first byte of each string is the same.
> It's should be redundant operation if strcmp == 0 but not in the case of
> strcmp is misbehaving.
> It's just a workaround. The correct fix is, of course, to fix the strcmp.
> Another workaround would be to use :
>
>
> -    if (strcmp(rpnt, lpnt) == 0) {
> +    if (memcmp(rpnt, lpnt,MAX_ISONAME+1) == 0) {
>
>
>
>
>>
>>  I think that genisoimage with that test is
>>> unable to generated any iso at all on big endian machines.
>>>
>> I cannot agree with this diagnosis.
>> Not having a big-endian machine at hand now, i can confirm from
>> my old SunOS-4-on-SPARC days that strcmp() is supposed to yield
>> a non-zero result with your example char arrays.
>>
>> strcmp() may well be implemented by word comparisons. But then it
>> is the duty of the implementation to properly handle the ends of
>> the strings even if those are not word aligned.
>>
> Indeed, the correct fix is using strcmp. Meanwhile, the package is broken.
>
>
Wow, that's pretty bad. How did that slip? Also, are you building 64-bit or
32-bit code, and what CPU architecture (perhaps some per-CPU implementation
is buggy but not others?) This information will help when tracking down the
issue.


>
>
>>
>>  I filed a bug with xorriso. Waiting for the number to show up.
>>>
>> I will hopefully get a notification via the pkg-libburnia-devel
>> list. Else i will bother you.
>>
>
> Hum, still no answer. I'm going to fill it again.
>
>
>
>>
>> Steve McIntyre:
>>
>>> We build all the release images on an amd64 machine, pettersson.d.o
>>>
>> Ok. That explains why there are sparc-bootable ISOs from xorriso.
>>
> I didn't imagine it could be doable.
>
>
>>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>>  Thanks for your time and dedication.
>
> Seb
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive: https://lists.debian.org/535E54EE.6050205@nerim.net
>
>

[Message part 2 (text/html, inline)]

Message #87 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Subject: Re: Bug#746254: xorriso: Sigbus on sparc when generating iso file.

Date: Mon, 28 Apr 2014 17:07:30 +0200

Hi,

> Program received signal SIGBUS, Bus error.
> add_worker (w_type=3, d=0x161128 <drive_array>, f=0xd1b20 <write_disc_worker_fun
> 149             a->u = *(union w_list_data *)data;

Other than expected from the first report in bug 731806,
the problem does not sit in libisofs but in libburn/async.c.
(Other predecessor developers to blame, if not myself.)

"a" is of type (struct w_list *). Its memory is created by calloc().
"data" is the address of a local variable struct (i.e. on stack).

struct w_list{
        /* ts A80714 */
        int w_type; /* see above define Burnworker_type_* */

        struct burn_drive *drive;
        pthread_t thread;

        struct w_list *next;

        union w_list_data
        {
                struct scan_opts scan;
                struct erase_opts erase;
                struct format_opts format;
                struct write_opts write;
                struct fifo_opts fifo;
        } u;
};

Callers of dd_worker use locally declared structs:
        struct scan_opts o;
        struct erase_opts o;
        struct format_opts o;
        struct write_opts o;
        struct fifo_opts o;
by handing over over their address like:
        add_worker(..., &o);

So
        a->u = *(union w_list_data *)data;
would be equivalent to
        memcpy(&(a->u), &o, sizeof(union w_list_data));

Hard to imagine what could cause an alignment problem here.
Well, maybe it suffices to replace the assignment by memcpy().

I'll make experiments with the login account provided by
Sébastien Bernard. First i need to reproduce the crash.


Have a nice day :)

Thomas

Message #92 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: Patrick Baggett <baggett.patrick@gmail.com>, Sébastien Bernard <sbernard@nerim.net>

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org, "debian-sparc@lists.debian.org" <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 18:25:39 +0200

[Message part 1 (text/plain, inline)]

Le 28/04/2014 16:05, Patrick Baggett a écrit :
> strcmp() may well be implemented by word comparisons. But then it
>
>         is the duty of the implementation to properly handle the ends of
>         the strings even if those are not word aligned.
>
>     Indeed, the correct fix is using strcmp. Meanwhile, the package is
>     broken.
>
>
> Wow, that's pretty bad. How did that slip? Also, are you building 
> 64-bit or 32-bit code, and what CPU architecture (perhaps some per-CPU 
> implementation is buggy but not others?) This information will help 
> when tracking down the issue.
>
I think this happens in this particular case comparing \000x and \0000.
I had a look at my test_case, the build is 32bit and the called function 
is dynamic in the glibc.
I tried a 64bit build, it's the same problem.
I tried various optimization flags and using __builtin_strcmp withtout 
any change.

Could you check this little program test against one of your machine ?
Just to be sure ?

Seb

[Message part 2 (text/html, inline)]

Message #97 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: Sébastien Bernard <sbernard@nerim.net>

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org, "debian-sparc@lists.debian.org" <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 11:31:37 -0500

[Message part 1 (text/plain, inline)]

On Mon, Apr 28, 2014 at 11:25 AM, Sébastien Bernard <sbernard@nerim.net>wrote:

>  Le 28/04/2014 16:05, Patrick Baggett a écrit :
>
>  strcmp() may well be implemented by word comparisons. But then it
>
>>  is the duty of the implementation to properly handle the ends of
>>> the strings even if those are not word aligned.
>>>
>>  Indeed, the correct fix is using strcmp. Meanwhile, the package is
>> broken.
>>
>>
>  Wow, that's pretty bad. How did that slip? Also, are you building 64-bit
> or 32-bit code, and what CPU architecture (perhaps some per-CPU
> implementation is buggy but not others?) This information will help when
> tracking down the issue.
>
>   I think this happens in this particular case comparing \000x and \0000.
> I had a look at my test_case, the build is 32bit and the called function
> is dynamic in the glibc.
> I tried a 64bit build, it's the same problem.
> I tried various optimization flags and using __builtin_strcmp withtout any
> change.
>
> Could you check this little program test against one of your machine ?
> Just to be sure ?
>
> Yeah sure, no problem -- I'll check it out soon. I'm somewhat comfortable
with SPARC assembly, so I'll see if I can dig a little deeper into why it
is failing.

[Message part 2 (text/html, inline)]

Message #102 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Cc: <sbernard@nerim.net>, <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 18:39:19 +0200

Hi,

sorry for mis-posting the first reply for bug 746254 to this bug 731806.

Meanwhile it turned out that the SIGBUS vanishes if i do not
compile with -O2 or if i replace "a->u =" by memcpy().

So it seems worth to check whether genisoimage resp. strcmp() work
properly if not compiled with -O2.

--------------------------------------------------------------------

A test with Sebastiens genisoimage options succeeded without error.

  /home/thomas/xorriso-1.3.7/xorriso/xorriso -as mkisofs \
      -r -J -o test.iso -G ~/boot/isofs.b -B ... tmp-iso/miniiso/cd_tree

It looks ok, SPARC-boot-wise.

  SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs
  SUN SPARC secs/head: 640
  SUN SPARC heads/cyl: 1
  SUN SPARC partmap  : N   IdTag   Perms    StartCyl   NumBlocks
  SUN SPARC partition: 1  0x0004  0x0010           0       16940
  SUN SPARC partition: 2  0x0002  0x0010           0       16940
  ...
  SUN SPARC partition: 8  0x0002  0x0010           0       16940

An additional option --md5 enabled confirmation that the ISO stream
of libisofs was written flawlessly by libburn into the file test.iso.

  /home/thomas/xorriso-1.3.7/xorriso/xorriso \
      -for_backup -indev test.iso -check_media --

xorriso is willing to load the ISO metadata and to compare it with
the hard disk tree.

  /home/thomas/xorriso-1.3.7/xorriso/xorriso \
      -indev test.iso -compare_r tmp-iso/miniiso/cd_tree /

It only detects the consequences of option -r with directories
(see man genisoimage / mkisofs):
Permissions are set to "r-xr-xr-x", owned by 0, group is 0.

--------------------------------------------------------------------

Have a nice day :)

Thomas

Message #107 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: Thomas Schmitt <scdbackup@gmx.net>

Cc: 731806@bugs.debian.org, Sébastien Bernard <sbernard@nerim.net>, "debian-sparc@lists.debian.org" <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 11:51:19 -0500

[Message part 1 (text/plain, inline)]

On Mon, Apr 28, 2014 at 11:39 AM, Thomas Schmitt <scdbackup@gmx.net> wrote:

> Hi,
>
> sorry for mis-posting the first reply for bug 746254 to this bug 731806.
>
> Meanwhile it turned out that the SIGBUS vanishes if i do not
> compile with -O2 or if i replace "a->u =" by memcpy().
>
> Could you explain the context around this code? Perhaps the source is not
really "alignment safe" and could use some patching upstream? I'd be happy
to provide advice or code samples.



> So it seems worth to check whether genisoimage resp. strcmp() work
> properly if not compiled with -O2.
>
> --------------------------------------------------------------------
>
> A test with Sebastiens genisoimage options succeeded without error.
>
>   /home/thomas/xorriso-1.3.7/xorriso/xorriso -as mkisofs \
>       -r -J -o test.iso -G ~/boot/isofs.b -B ... tmp-iso/miniiso/cd_tree
>
> It looks ok, SPARC-boot-wise.
>
>   SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by libisofs
>   SUN SPARC secs/head: 640
>   SUN SPARC heads/cyl: 1
>   SUN SPARC partmap  : N   IdTag   Perms    StartCyl   NumBlocks
>   SUN SPARC partition: 1  0x0004  0x0010           0       16940
>   SUN SPARC partition: 2  0x0002  0x0010           0       16940
>   ...
>   SUN SPARC partition: 8  0x0002  0x0010           0       16940
>
> An additional option --md5 enabled confirmation that the ISO stream
> of libisofs was written flawlessly by libburn into the file test.iso.
>
>   /home/thomas/xorriso-1.3.7/xorriso/xorriso \
>       -for_backup -indev test.iso -check_media --
>
> xorriso is willing to load the ISO metadata and to compare it with
> the hard disk tree.
>
>   /home/thomas/xorriso-1.3.7/xorriso/xorriso \
>       -indev test.iso -compare_r tmp-iso/miniiso/cd_tree /
>
> It only detects the consequences of option -r with directories
> (see man genisoimage / mkisofs):
> Permissions are set to "r-xr-xr-x", owned by 0, group is 0.
>
> --------------------------------------------------------------------
>
> Have a nice day :)
>
> Thomas
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive:
> https://lists.debian.org/18128670805771551827@scdbackup.webframe.org
>
>

[Message part 2 (text/html, inline)]

Message #112 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Cc: <baggett.patrick@gmail.com>, <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 19:25:53 +0200

Hi,

Patrick Baggett:
> Could you explain the context around this code? Perhaps the source is
> not really "alignment safe" and could use some patching upstream? I'd
> be happy to provide advice or code samples.

The context was misposted to bug report 731806 as message #87:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731806#87
(but not with Cc to debian-sparc list).

Upstream is myself. :))
The code in question is by my unreachable libburn predecessors, though.

It belongs to the preparation of a thread start for one of five
occasions in libburn. SIGBUS happens at
  http://libburnia-project.org/browser/libburn/trunk/libburn/async.c#L149

The caller has a local struct (i.e. on stack) like (#L592, #L692):

   struct write_opts write;
   ...
   add_worker(Burnworker_type_writE, d,
                   (WorkerFunc) write_disc_worker_func, &o);

The called function gets its address as parameter "data" (#L135):

  static void add_worker(int w_type, struct burn_drive *d,
                         WorkerFunc f, void *data)

has a struct on heap (#L102, #L138, #L146):

   struct w_list{
       ...
       union w_list_data
       {
           ...
           struct write_opts write;
           ...
       } u;
   }
   ...
   struct w_list *a;
   ...
   a = calloc(1, sizeof(struct w_list));

The gesture which causes the SIGBUS is (#L149)

   a->u = *(union w_list_data *)data;

which is not what i personally would use, but should be fully legal
nevertheless.

The SIGBUS vanishes if i compile without gcc -O2, or if i replace
the "a->u =" gesture by

   memcpy(&(a->u), data, sizeof(union w_list_data));

which i deem equivalent (and more my personal style).


Have a nice day :)

Thomas

Message #117 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Cc: <baggett.patrick@gmail.com>, <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 19:33:40 +0200

Hi,

i wrote:
>   struct write_opts write;
>   ...
>   add_worker(Burnworker_type_writE, d,
>                   (WorkerFunc) write_disc_worker_func, &o);

Urgh. I copied the wrong struct definition. Line 592 bears of course:

    struct write_opts o;

which is used in the call of add_worker().


Have a nice day :)

Thomas

Message #122 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: Thomas Schmitt <scdbackup@gmx.net>

Cc: 731806@bugs.debian.org, "debian-sparc@lists.debian.org" <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 12:55:02 -0500

[Message part 1 (text/plain, inline)]

On Mon, Apr 28, 2014 at 12:25 PM, Thomas Schmitt <scdbackup@gmx.net> wrote:

> Hi,
>
> Patrick Baggett:
> > Could you explain the context around this code? Perhaps the source is
> > not really "alignment safe" and could use some patching upstream? I'd
> > be happy to provide advice or code samples.
>
> The context was misposted to bug report 731806 as message #87:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731806#87
> (but not with Cc to debian-sparc list).
>
> Upstream is myself. :))
> The code in question is by my unreachable libburn predecessors, though.
>
> It belongs to the preparation of a thread start for one of five
> occasions in libburn. SIGBUS happens at
>   http://libburnia-project.org/browser/libburn/trunk/libburn/async.c#L149
>
> The caller has a local struct (i.e. on stack) like (#L592, #L692):
>
>    struct write_opts write;
>    ...
>    add_worker(Burnworker_type_writE, d,
>                    (WorkerFunc) write_disc_worker_func, &o);
>
> The called function gets its address as parameter "data" (#L135):
>
>   static void add_worker(int w_type, struct burn_drive *d,
>                          WorkerFunc f, void *data)
>
> has a struct on heap (#L102, #L138, #L146):
>
>    struct w_list{
>        ...
>        union w_list_data
>        {
>            ...
>            struct write_opts write;
>            ...
>        } u;
>    }
>    ...
>    struct w_list *a;
>    ...
>    a = calloc(1, sizeof(struct w_list));
>
> The gesture which causes the SIGBUS is (#L149)
>
>    a->u = *(union w_list_data *)data;
>
> which is not what i personally would use, but should be fully legal
> nevertheless.
>
>
I'm not sure what the problem is exactly here. 64-bit SPARC will use ldx to
load 64-bit quantities, which can cause problems if the source data is only
4-byte aligned, but that doesn't seem to be the case here. I really need a
disassembly and to be able to probe the runtime stack a bit, so that really
means that I need to build the code. :)

I think as a more meta-problem is this: the code's logic for "how much" to
copy is wrong. It copies too many bytes on many cases and violates the C
contract that you'll only copy like objects using "=".

Imagine:

sizeof(struct erase_ops) == 8 (32-bit ABI)
sizeof(w_list_data) == at least 12 (32-bit ABI).

Suppose: data = &some_erase_ops

a->u = *(union w_list_data *)data; // copies 12 bytes from 8 byte area, can
cause crashes if the last 4 bytes are into an unmapped page.


The correct way to do this would be to have add_worker() pass a const
w_list_data* with the appropriate field(s) in '.u' filled out. Otherwise,
you're copying unlike objects *of different sizes* and that's never safe.

---

Patrick




> The SIGBUS vanishes if i compile without gcc -O2, or if i replace
> the "a->u =" gesture by
>
>    memcpy(&(a->u), data, sizeof(union w_list_data));
>
> which i deem equivalent (and more my personal style).
>
>
> Have a nice day :)
>
> Thomas
>
>

[Message part 2 (text/html, inline)]

Message #127 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Cc: <baggett.patrick@gmail.com>, <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 20:20:15 +0200

Hi,

> I really need a disassembly and to be able to probe the runtime
> stack a bit, so that really means that I need to build the code. :)

The current example would be a bit too opulent, i guess:

  -rwxr-xr-x 1 thomas thomas 3753398 avril 28 17:49 xorriso/xorriso

(wget http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz
 untar, cd xorriso-1.3.2, ./configure, make, ls -l xorriso/xorriso,
 crash by:
    xorriso/xorriso -outdev stdio:/dev/null -map ./xorriso /
)

I'll try to reproduce by a smaller program on Sebastien's
system.


> I think as a more meta-problem is this: the code's logic for "how
> much" to copy is wrong. It copies too many bytes on many cases and
> violates the C contract that you'll only copy like objects using "=".
> [...] you're copying unlike objects of different sizes and
> that's never safe.

It's the job of a C union to provide a common hull around objects
of different size. One may dispute whether using union is a good
idea (like overloading in the OO paradigm). But unions are part of C
since K&R and they are supposed to be safe.
  http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Size-of-Unions

As for the cost: The threads are running big operations of libburn.
Even a full MB of copying would not make much difference.

Elsewise i agree with you. I would have written it differently, too.
But i will try to keep the necessary changes as small as possible.
So the union approach will most probably stay unless i get convinced
that it is faulty C language.


Have a nice day :)

Thomas

Message #132 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: Sébastien Bernard <sbernard@nerim.net>

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org, "debian-sparc@lists.debian.org" <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 13:21:07 -0500

[Message part 1 (text/plain, inline)]

Seb,

Yes, I can reproduce this issue.

{ 1, 0 }
{ 1, 1 }

returns 0, when it should return -1.


Interestingly, if you use:
{ 1, 1, 1, 1, 0 }  //i.e. 5 bytes
{ 1, 1, 1, 1, 1 }  //i.e. 5 bytes

as the strings, it returns -1. So it clearly has a problem if the string is
exceptionally short. That got me thinking. How short?

{ 1, 1, 1, 0 }  //i.e. 4 bytes, returns -1
{ 1, 1, 1, 1 }

{ 1, 1, 0 }  //i.e. 3 bytes, returns -1
{ 1, 1, 1 }

{ 1, 0 }  //i.e. 2 bytes, return -1
{ 1, 1 }

{ 0 }  //i.e. 1 byte, returns -1 : HOLD ON, WHAT?
{ 1 }

----
So the 1-bye case succeeded, but why? The only difference between that and
the failing case was two null bytes which shouldn't even be examined.
----

{ 0, 0 }  //i.e. original test case. Fails, returns 0
{ 1, 0 }

{ 1, 0, 0 } //fails, returns 0.
{ 1, 1, 0 }

{ 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 0 }

{ 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 0 }

{ 1, 1, 1, 1, 0, 0 } //fails, returns 0.
{ 1, 1, 1, 1, 1, 0 }

... ok ... ?

So apparently, ending with a null character that shouldn't even be examined
messes things up? Let's try something radically different:

{ 1, 1, 1, 1, 0, 0xaa } //returns -1, OK
{ 1, 1, 1, 1, 1, 0 }

{ 1, 1, 1, 1, 0, 0 } //returns -1, OK
{ 1, 1, 1, 1, 1, 0xaa }

{ 1, 1, 1, 1, 0, 0xaa} //returns -1, OK
{ 1, 1, 1, 1, 1, 0xbb }





On Mon, Apr 28, 2014 at 6:35 AM, Sébastien Bernard <sbernard@nerim.net>wrote:

> Le 28/04/2014 13:20, Thomas Schmitt a écrit :
>
>
>>  [genisoimage]
>>> (gdb) x rpnt
>>> 0x1ea7f9:    0x00000000
>>> (gdb) x lpnt
>>> 0x1e9dc1:    0x01000000
>>> (gdb) n
>>> 659        if (strcmp(rpnt, lpnt) == 0) {
>>>
>> Both values match the prescribed names for "." and ".." in ECMA-119
>> (aka ISO 9660), 6.8.2.2 Identification of directories:
>> Single byte 0x00 is ".", single byte 0x01 is "..".
>>
> Ok, I got the bug nailed.
> Here's a sample session from my sparc:
> ----------
> cat  test_strcmp.c<<EOF
> #include <stdio.h>
> #include <stdlib.h>
>
> void main(void) {
>   char stra[2];
>   char strb[2];
>   int result = 0;
>
>   stra[0] = 0;
>   stra[1] = 0;
>   strb[0] = 1;
>   strb[1] = 0;
>
>   result = strcmp(stra,strb);
>
>   printf("result from strcmp('\\0000','\\0001' is %d)\n",result);
>   exit(0);
> }
> EOF
> gcc -o test_strcmp test_strcmp.c
> ./test_strcmp
> result from strcmp('\0000','\0001' is 0)
> ----------
>
> Here's the same sample from my intel workstation:
> ----------
> gcc -o test_strcmp test_strcmp.c
> ./test_strcmp
> result from strcmp('\0000','\0001' is -1)
> ----------
>
> Typicaly, an endianness error.
>
> If I apply this patch on cdrkit:
> --- genisoimage/write.c    2014-04-28 13:31:28.103571175 +0200
> +++ genisoimage/write.c.new    2014-04-28 13:31:07.255433923 +0200
> @@ -656,7 +656,7 @@
>  #endif    /* APPLE_HYB */
>
>      /* If the entries are the same, this is an error. */
>
> -    if (strcmp(rpnt, lpnt) == 0) {
> +    if (strcmp(rpnt, lpnt) == 0 && rpnt[0] == lpnt[0]) {
>  #ifdef    USE_LIBSCHILY
>          errmsgno(EX_BAD,
>              "Error: '%s' and '%s' have the same ISO9660 name '%s'.\n",
>
> Then the iso is correctly generated.
>
> I'll file a bug with cdrkit. I think that genisoimage with that test is
> unable to generated any iso at all on big endian machines.
>
>  So, strcmp shouldn't have yielded 0 when comparing the strings.
>>>
>> Can this be caused by alignment problems ?
>>
> Nope.
>
>
>>
>>  Hum, unfortunately, valgrind is not available for sparc.
>>>
>> Then gdb will have to do.
>>
>>
>>  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.
>>>
>> If you also built libisofs and libburn from source, then this burries
>> my theory of a binary incompatibility between two SPARC machines.
>>
>>  I'm compiling at this moment the vanilla xorriso from gnu.
>>> Let's see what it yields.
>>>
>> It has the same source as the three library tarballs used as input
>> for Debian's xorriso. Only difference is that GNU xorriso brings
>> own copies of the library source code and links it statically with
>> the xorriso main program.
>> So it can be easily tested without interfering with installations
>> of the libraries. (And with no need for superuser privileges.)
>>
> I filed a bug with xorriso. Waiting for the number to show up.
>
>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
>>  You too ; ).
>
> Seb
>
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive: https://lists.debian.org/535E3CF6.3080601@nerim.net
>
>

[Message part 2 (text/html, inline)]

Message #137 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: Thomas Schmitt <scdbackup@gmx.net>

Cc: 731806@bugs.debian.org, "debian-sparc@lists.debian.org" <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 13:30:01 -0500

[Message part 1 (text/plain, inline)]

On Mon, Apr 28, 2014 at 1:20 PM, Thomas Schmitt <scdbackup@gmx.net> wrote:

> Hi,
>
> > I really need a disassembly and to be able to probe the runtime
> It's the job of a C union to provide a common hull around objects
> of different size. One may dispute whether using union is a good
> idea (like overloading in the OO paradigm). But unions are part of C
> since K&R and they are supposed to be safe.
>
> http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Size-of-Unions


No, it's plain wrong. Unions are fine, if used properly. You aren't using
them properly. Let me show you how by a more extreme example:

#include <stdlib.h>

struct small {
   int a;
};

struct big {
   int b[1024*1024];
};

union both {
   struct small imSmall;
   struct big imBig;
};


void copy(union both* b, void* data) {

    *b = *(union both*)data; //copies 4MB of data.
}

void main() {
    struct small smallThing;
    union both* bothThings = malloc(sizeof(union both));
    copy(bothThings, &smallThing); // NOT OK. struct small cannot NOT be
converted to union both.
}

figgles@ghost:~$ ./big
Segmentation fault
----
The problem is that union can convert to a member (by accessing the field),
but a member CANNOT convert to a union. add_worker() takes a member and
tries to convert it to a union. This is WRONG. Period.

[Message part 2 (text/html, inline)]

Message #142 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Cc: <baggett.patrick@gmail.com>, <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 20:55:03 +0200

Hi,

> No, it's plain wrong. Unions are fine, if used properly. You aren't
> using them properly.

Duh. You convinced me. The callers do it wrong, indeed.
They would have to use local union variables instead of their actual
structs. The parameter of add_worker() should be a pointer to the
union, not a pointer to void.

Obviously the bug normally stays withing populated stack area.
Three cheers for the picky systems !

I'll stop the attempt to reproduce the problem in a smaller program
and rather fix libburn.
(That will result in some testing plight on the less picky systems.)

Thank you for pointing me to this bug.


Have a nice day :)

Thomas

Message #147 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Richard Mortimer <richm@oldelvet.org.uk>

To: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Cc: baggett.patrick@gmail.com, debian-sparc@lists.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 19:54:52 +0100

Hi,

On 28/04/2014 18:25, Thomas Schmitt wrote:

> has a struct on heap (#L102, #L138, #L146):
>
>     struct w_list{
>         ...
>         union w_list_data
>         {
>             ...
>             struct write_opts write;
>             ...
>         } u;
>     }
>     ...
>     struct w_list *a;
>     ...
>     a = calloc(1, sizeof(struct w_list));
>
> The gesture which causes the SIGBUS is (#L149)
>
>     a->u = *(union w_list_data *)data;
>
The issue is that data needs to be suitably aligned on an appropriate 
memory boundary. SPARC requires that int32 accesses are aligned on 4 
byte boundaries and that int64 aligns on 8 byte boundaries.

You have to arrange that data is properly aligned or you will get a 
SIGBUS due to an address misalignment.

malloc and calloc arrange that the alignment is suitable

(the manpage says)

"RETURN VALUE
The malloc() and calloc() functions return a pointer to  the  allocated
memory  that  is  suitably aligned for any kind of variable. "

I'm guessing that your void *data isn't directly allocated by calloc so 
it doesn't necessarily have the correct alignment.


> which is not what i personally would use, but should be fully legal
> nevertheless.
>
> The SIGBUS vanishes if i compile without gcc -O2, or if i replace
> the "a->u =" gesture by
>
>     memcpy(&(a->u), data, sizeof(union w_list_data));
>
> which i deem equivalent (and more my personal style).

The memcpy version will work just fine because memcpy takes 
misalignments into account and once the data has been copied into a->u 
the calloc'd version of struct w_list will be properly aligned because 
calloc guarantees that it will be.

memcpy is the correct thing to use in your case.

Regards

Richard

Message #152 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Cc: <baggett.patrick@gmail.com>, <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 22:01:57 +0200

Hi,

Sebastien's machine now has a xorriso-1.3.7 (the current development
snapshot) with changed libburn/async.c.

The callers of add_worker() now declare:

        union w_list_data o;

rather than

        struct union_member o;

The type of the fourth parameter of add_worker has been changed
from (void *) to (union w_list_data *).

The formerly SIGBUSsing statement became quite elegant

        a->u = *data;

Given that it is a good bug catcher on Debian sparc, and more concise
than e.g.
        memcpy(&(a->u), data, sizeof(union w_list_data));
i tend to keep it.


To Sebastien:

Please give
   /home/thomas/xorriso-1.3.7/xorriso/xorriso
a thorough testing with your debian-cd setup.
("make dist" should even pack it up to a usable tarball)

Whatever the outcome will be with that strange strcmp() bug,
your original alternatives 1 and 2 have small chances to succeed
unless we declare surrender on 3.

1- It has been publicly stated in the past that Debian will not
   accept a package with original mkisofs. Stated reason was social
   incompatibility with its author.

2- Steve McIntyre prefers xorriso to take over genisoimage tasks
   rather than changing genisoimage code.
   From his view, xorriso is comfortably self-maintaining. :))
   I try to give him few reason to regret this strategy.

3- A xorriso candidate (rather stack sanitized than alignment
   corrected) has now been beamed onto your machine.


Have a nice day :)

Thomas

Message #157 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Cc: baggett.patrick@gmail.com, debian-sparc@lists.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 22:25:08 +0200

Le 28/04/2014 22:01, Thomas Schmitt a écrit :
> Hi,
>
> Sebastien's machine now has a xorriso-1.3.7 (the current development
> snapshot) with changed libburn/async.c.
>
> The callers of add_worker() now declare:
>
>          union w_list_data o;
>
> rather than
>
>          struct union_member o;
>
> The type of the fourth parameter of add_worker has been changed
> from (void *) to (union w_list_data *).
>
> The formerly SIGBUSsing statement became quite elegant
>
>          a->u = *data;
>
> Given that it is a good bug catcher on Debian sparc, and more concise
> than e.g.
>          memcpy(&(a->u), data, sizeof(union w_list_data));
> i tend to keep it.
>
>
> To Sebastien:
>
> Please give
>     /home/thomas/xorriso-1.3.7/xorriso/xorriso
> a thorough testing with your debian-cd setup.
> ("make dist" should even pack it up to a usable tarball)
>
> Whatever the outcome will be with that strange strcmp() bug,
> your original alternatives 1 and 2 have small chances to succeed
> unless we declare surrender on 3.
>
> 1- It has been publicly stated in the past that Debian will not
>     accept a package with original mkisofs. Stated reason was social
>     incompatibility with its author.
>
> 2- Steve McIntyre prefers xorriso to take over genisoimage tasks
>     rather than changing genisoimage code.
>     From his view, xorriso is comfortably self-maintaining. :))
>     I try to give him few reason to regret this strategy.
>
> 3- A xorriso candidate (rather stack sanitized than alignment
>     corrected) has now been beamed onto your machine.
>
>
> Have a nice day :)
>
> Thomas
>
>
Thomas,

I'm trying to rebuild from sid now, since sparc has been removed from 
jessie.

Cheers

Seb

Message #162 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: Sébastien Bernard <sbernard@nerim.net>, Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org

Cc: baggett.patrick@gmail.com, debian-sparc@lists.debian.org

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 22:48:35 +0200

Le 28/04/2014 22:25, Sébastien Bernard a écrit :
> Le 28/04/2014 22:01, Thomas Schmitt a écrit :
>> Hi,
>>
>> Sebastien's machine now has a xorriso-1.3.7 (the current development
>> snapshot) with changed libburn/async.c.
>>
>> The callers of add_worker() now declare:
>>
>>          union w_list_data o;
>>
>> rather than
>>
>>          struct union_member o;
>>
>> The type of the fourth parameter of add_worker has been changed
>> from (void *) to (union w_list_data *).
>>
>> The formerly SIGBUSsing statement became quite elegant
>>
>>          a->u = *data;
>>
>> Given that it is a good bug catcher on Debian sparc, and more concise
>> than e.g.
>>          memcpy(&(a->u), data, sizeof(union w_list_data));
>> i tend to keep it.
>>
>>
>> To Sebastien:
>>
>> Please give
>>     /home/thomas/xorriso-1.3.7/xorriso/xorriso
>> a thorough testing with your debian-cd setup.
>> ("make dist" should even pack it up to a usable tarball)
>>
>> Whatever the outcome will be with that strange strcmp() bug,
>> your original alternatives 1 and 2 have small chances to succeed
>> unless we declare surrender on 3.
>>
>> 1- It has been publicly stated in the past that Debian will not
>>     accept a package with original mkisofs. Stated reason was social
>>     incompatibility with its author.
>>
>> 2- Steve McIntyre prefers xorriso to take over genisoimage tasks
>>     rather than changing genisoimage code.
>>     From his view, xorriso is comfortably self-maintaining. :))
>>     I try to give him few reason to regret this strategy.
>>
>> 3- A xorriso candidate (rather stack sanitized than alignment
>>     corrected) has now been beamed onto your machine.
>>
>>
>> Have a nice day :)
>>
>> Thomas
>>
>>
> Thomas,
>
> I'm trying to rebuild from sid now, since sparc has been removed from 
> jessie.
>
> Cheers
>
> Seb
Two thumbs up thomas :
xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B 
... ./tmp/miniiso/cd_tree
GNU xorriso 1.3.7 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:./tmp/miniiso/mini.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 8791m free
Added to ISO image: directory 
'/'='/home/seb/dev/debian-installer-20140316/build/tmp/miniiso/cd_tree'
xorriso : UPDATE : 7 files added in 1 seconds
xorriso : UPDATE : 7 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 7040 bytes from file 
'/boot/isofs.b'
ISO image produced: 4235 sectors
Written to medium : 4235 sectors at LBA 0
Writing to 'stdio:./tmp/miniiso/mini.iso' completed successfully.

So the package was built ok.

Cheers to team work.

Seb

Message #167 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: Patrick Baggett <baggett.patrick@gmail.com>

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org, "debian-sparc@lists.debian.org" <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Mon, 28 Apr 2014 22:50:00 +0200

Le 28/04/2014 20:21, Patrick Baggett a écrit :
> Seb,
>
> Yes, I can reproduce this issue.
>
> { 1, 0 }
> { 1, 1 }
>
> returns 0, when it should return -1.
>
>
> Interestingly, if you use:
> { 1, 1, 1, 1, 0 }  //i.e. 5 bytes
> { 1, 1, 1, 1, 1 }  //i.e. 5 bytes
>
> as the strings, it returns -1. So it clearly has a problem if the 
> string is exceptionally short. That got me thinking. How short?
>
> { 1, 1, 1, 0 }  //i.e. 4 bytes, returns -1
> { 1, 1, 1, 1 }
>
> { 1, 1, 0 }  //i.e. 3 bytes, returns -1
> { 1, 1, 1 }
>
> { 1, 0 }  //i.e. 2 bytes, return -1
> { 1, 1 }
>
> { 0 }  //i.e. 1 byte, returns -1 : HOLD ON, WHAT?
> { 1 }
>
> ----
> So the 1-bye case succeeded, but why? The only difference between that 
> and the failing case was two null bytes which shouldn't even be examined.
> ----
>
> { 0, 0 }  //i.e. original test case. Fails, returns 0
> { 1, 0 }
>
> { 1, 0, 0 } //fails, returns 0.
> { 1, 1, 0 }
>
> { 1, 1, 0, 0 } //fails, returns 0.
> { 1, 1, 1, 0 }
>
> { 1, 1, 1, 0, 0 } //fails, returns 0.
> { 1, 1, 1, 1, 0 }
>
> { 1, 1, 1, 1, 0, 0 } //fails, returns 0.
> { 1, 1, 1, 1, 1, 0 }
>
Ok, I think it's time to file a bug to the glibc.

Seb

Message #172 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Thomas Schmitt" <scdbackup@gmx.net>

To: 731806@bugs.debian.org

Cc: <baggett.patrick@gmail.com>, <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 09:06:55 +0200

Hi,

Sébastien Bernard:
> Cheers to team work.

Special cheers to Patrick Baggett !

And thanks to all who cared for this problem. I'd need more
users who don't shrug but complain and tell me that i'm wrong.

The bug fix is now committed as
  http://libburnia-project.org/changeset/5324

(We still did not find any alignment problem. Does that mean
 we did not test hard enough ?)


> The real function is in sysdeps/sparc/sparc64/strcmp.S .
> So complicated that I'm not surprised a bug came inside.

I found a medium complicated one in the libc code which
you provided for me in /home/thomas
  eglibc-2.18/string/bits/string2.h
Already too bloated for me to spot any mistake or correctness.


Have a nice day :)

Thomas

Message #177 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Kieron Gillespie <ciaran.gillespie@gmail.com>

To: Thomas Schmitt <scdbackup@gmx.net>

Cc: 731806@bugs.debian.org, Patrick Baggett <baggett.patrick@gmail.com>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 10:34:45 -0400

[Message part 1 (text/plain, inline)]

I am currently investigating this unusual behavior with strcmp, and I am
unable to reproduce the problem using the test_strcmp example provided.

It returns the correct output of,

result from strcmp('\0000','\0001' is -1)

This was built on Debian Wheezy with a T2000 SPARC processor using GCC
4.6.3-14 from Debian Wheezy Repo.

Cheers,
Kieron


On Tue, Apr 29, 2014 at 3:06 AM, Thomas Schmitt <scdbackup@gmx.net> wrote:

> Hi,
>
> Sébastien Bernard:
> > Cheers to team work.
>
> Special cheers to Patrick Baggett !
>
> And thanks to all who cared for this problem. I'd need more
> users who don't shrug but complain and tell me that i'm wrong.
>
> The bug fix is now committed as
>   http://libburnia-project.org/changeset/5324
>
> (We still did not find any alignment problem. Does that mean
>  we did not test hard enough ?)
>
>
> > The real function is in sysdeps/sparc/sparc64/strcmp.S .
> > So complicated that I'm not surprised a bug came inside.
>
> I found a medium complicated one in the libc code which
> you provided for me in /home/thomas
>   eglibc-2.18/string/bits/string2.h
> Already too bloated for me to spot any mistake or correctness.
>
>
> Have a nice day :)
>
> Thomas
>
>
> --
> To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive:
> https://lists.debian.org/30925670721203172670@scdbackup.webframe.org
>
>

[Message part 2 (text/html, inline)]

Message #182 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: Kieron Gillespie <ciaran.gillespie@gmail.com>, Thomas Schmitt <scdbackup@gmx.net>

Cc: 731806@bugs.debian.org, Patrick Baggett <baggett.patrick@gmail.com>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 16:45:58 +0200

Le 29/04/2014 16:34, Kieron Gillespie a écrit :
> I am currently investigating this unusual behavior with strcmp, and I 
> am unable to reproduce the problem using the test_strcmp example provided.
>
> It returns the correct output of,
>
> result from strcmp('\0000','\0001' is -1)
>
> This was built on Debian Wheezy with a T2000 SPARC processor using GCC 
> 4.6.3-14 from Debian Wheezy Repo.
>
> Cheers,
> Kieron
>
Hum, I tried with a T5220 with debian 7.5 /wheezy.
Same result, the strcmp is ok.
Could you try with unstable ?

Cheers.

Message #187 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: Kieron Gillespie <ciaran.gillespie@gmail.com>

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 09:47:27 -0500

[Message part 1 (text/plain, inline)]

On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
ciaran.gillespie@gmail.com> wrote:

> I am currently investigating this unusual behavior with strcmp, and I am
> unable to reproduce the problem using the test_strcmp example provided.
>
> It returns the correct output of,
>
>
> result from strcmp('\0000','\0001' is -1)
>
> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
> 4.6.3-14 from Debian Wheezy Repo.
>
>
Can you set a breakpoint in strcmp and tell me what the file path is?
Perhaps there is a sun4v specific function (optimized version) that does
not have a bug?

Patrick

[Message part 2 (text/html, inline)]

Message #192 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Kieron Gillespie <ciaran.gillespie@gmail.com>

To: Sébastien Bernard <sbernard@nerim.net>

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org, Patrick Baggett <baggett.patrick@gmail.com>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 10:50:07 -0400

[Message part 1 (text/plain, inline)]

I'll rebuild one of my SunBlade 2500 latter with sid and see if I get the
same result. If it doesn't show the symptom I will rebuild my T2000 and see
if it is something specific to the Niagara T1.

-Kieron


On Tue, Apr 29, 2014 at 10:45 AM, Sébastien Bernard <sbernard@nerim.net>wrote:

> Le 29/04/2014 16:34, Kieron Gillespie a écrit :
>
>  I am currently investigating this unusual behavior with strcmp, and I am
>> unable to reproduce the problem using the test_strcmp example provided.
>>
>> It returns the correct output of,
>>
>> result from strcmp('\0000','\0001' is -1)
>>
>> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
>> 4.6.3-14 from Debian Wheezy Repo.
>>
>> Cheers,
>> Kieron
>>
>>  Hum, I tried with a T5220 with debian 7.5 /wheezy.
> Same result, the strcmp is ok.
> Could you try with unstable ?
>
> Cheers.
>
>

[Message part 2 (text/html, inline)]

Message #197 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Kieron Gillespie <ciaran.gillespie@gmail.com>

To: Patrick Baggett <baggett.patrick@gmail.com>

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 11:01:53 -0400

[Message part 1 (text/plain, inline)]

On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett <baggett.patrick@gmail.com
> wrote:

>
>
> On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
> ciaran.gillespie@gmail.com> wrote:
>
>> I am currently investigating this unusual behavior with strcmp, and I am
>> unable to reproduce the problem using the test_strcmp example provided.
>>
>> It returns the correct output of,
>>
>>
>> result from strcmp('\0000','\0001' is -1)
>>
>> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
>> 4.6.3-14 from Debian Wheezy Repo.
>>
>>
> Can you set a breakpoint in strcmp and tell me what the file path is?
> Perhaps there is a sun4v specific function (optimized version) that does
> not have a bug?
>
> Patrick
>
>

Here is the information from strcmp breakpoint

---CUT---
Breakpoint 1, 0xf7ebd300 in strcmp () from /lib/sparc-linux-gnu/libc.so.6
(gdb) disas strcmp
Dump of assembler code for function strcmp:
=> 0xf7ebd300 <+0>:     sethi  %hi(0x1010000), %g1
   0xf7ebd304 <+4>:     btst  7, %o0
   0xf7ebd308 <+8>:     bne,pn   %icc, 0xf7ebd4a0 <strcmp+416>
   0xf7ebd30c <+12>:    or  %g1, 0x101, %g1
   0xf7ebd310 <+16>:    andcc  %o1, 7, %g3
   0xf7ebd314 <+20>:    bne,pn   %icc, 0xf7ebd4e4 <strcmp+484>
   0xf7ebd318 <+24>:    sllx  %g1, 0x20, %g2
   0xf7ebd31c <+28>:    ldx  [ %o0 ], %o2
---CUT---

As far as I can tell from stepping through this it seems like a correctly
implementation of strcmp.

---CUT---
(gdb) info reg
g0             0x0      0
g1             0x20754  132948
g2             0x33dfaf4        54393588
g3             0x3dfaf4 4061940
g4             0xf869cbac       -127284308
g5             0x28     40
g6             0xfeff   65279
g7             0xf7ff66d0       -134256944
o0             0xffffdc48       -9144
o1             0xffffdc50       -9136
o2             0xffffdd34       -8908
---CUT---

You can see that o0 and o1 are holding the pointers for the strings
correctly and examining the value of memory at those location appears to be
correct.

With -O3 the call is the same. So I am not sure what is going on, would
like to see an "info reg" at the breakpoint of strcmp on the affected
systems. Also an examiniation of the memory that o0 and o1 are pointing too.

-Kieron

[Message part 2 (text/html, inline)]

Message #202 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: Kieron Gillespie <ciaran.gillespie@gmail.com>

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 10:16:06 -0500

[Message part 1 (text/plain, inline)]

On Tue, Apr 29, 2014 at 10:01 AM, Kieron Gillespie <
ciaran.gillespie@gmail.com> wrote:

>
> On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett <
> baggett.patrick@gmail.com> wrote:
>
>>
>>
>> On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
>> ciaran.gillespie@gmail.com> wrote:
>>
>>> I am currently investigating this unusual behavior with strcmp, and I am
>>> unable to reproduce the problem using the test_strcmp example provided.
>>>
>>> It returns the correct output of,
>>>
>>>
>>> result from strcmp('\0000','\0001' is -1)
>>>
>>> This was built on Debian Wheezy with a T2000 SPARC processor using GCC
>>> 4.6.3-14 from Debian Wheezy Repo.
>>>
>>>
>> Can you set a breakpoint in strcmp and tell me what the file path is?
>> Perhaps there is a sun4v specific function (optimized version) that does
>> not have a bug?
>>
>> Patrick
>>
>>
>
> Here is the information from strcmp breakpoint
>
> ---CUT---
> Breakpoint 1, 0xf7ebd300 in strcmp () from /lib/sparc-linux-gnu/libc.so.6
> (gdb) disas strcmp
> Dump of assembler code for function strcmp:
> => 0xf7ebd300 <+0>:     sethi  %hi(0x1010000), %g1
>    0xf7ebd304 <+4>:     btst  7, %o0
>    0xf7ebd308 <+8>:     bne,pn   %icc, 0xf7ebd4a0 <strcmp+416>
>    0xf7ebd30c <+12>:    or  %g1, 0x101, %g1
>    0xf7ebd310 <+16>:    andcc  %o1, 7, %g3
>    0xf7ebd314 <+20>:    bne,pn   %icc, 0xf7ebd4e4 <strcmp+484>
>    0xf7ebd318 <+24>:    sllx  %g1, 0x20, %g2
>    0xf7ebd31c <+28>:    ldx  [ %o0 ], %o2
> ---CUT---
>
> They aren't the same implementation. Look:

        or      rSTR2, rSTR1, rTMP1
        sethi   %hi(0x80808080), r8080
        andcc   rTMP1, 0x7, %g0
        bne,pn  %icc, .Lmaybe_barrel_shift
         or     r8080, %lo(0x80808080), r8080
        ldx     [rSTR1], rWORD1
        sub     rSTR2, rSTR1, rSTR2
        sllx    r8080, 32, rTMP1
        ldx     [rSTR1 + rSTR2], rWORD2
        or      r8080, rTMP1, r8080


Side by side, the instructions aren't even the same:

Failing   | Working
----------+--------
or        | sethi 0x1010
sethi 8080| btst
btst*     | bne
bne       | or 0x101
or 808    | andcc ... %g3
ldx       | bne
sub       | sllx
sllx      | ldx
 ...

*btst  rA, rB -> andcc rA, rB, %g0



As far as I can tell from stepping through this it seems like a correctly
> implementation of strcmp.
>
> ---CUT---
> (gdb) info reg
> g0             0x0      0
> g1             0x20754  132948
> g2             0x33dfaf4        54393588
> g3             0x3dfaf4 4061940
> g4             0xf869cbac       -127284308
> g5             0x28     40
> g6             0xfeff   65279
> g7             0xf7ff66d0       -134256944
> o0             0xffffdc48       -9144
> o1             0xffffdc50       -9136
> o2             0xffffdd34       -8908
> ---CUT---
>
> You can see that o0 and o1 are holding the pointers for the strings
> correctly and examining the value of memory at those location appears to be
> correct.
>
> With -O3 the call is the same. So I am not sure what is going on, would
> like to see an "info reg" at the breakpoint of strcmp on the affected
> systems. Also an examiniation of the memory that o0 and o1 are pointing too.
>
> -Kieron
>
>

[Message part 2 (text/html, inline)]

Message #207 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: Kieron Gillespie <ciaran.gillespie@gmail.com>

Cc: Thomas Schmitt <scdbackup@gmx.net>, 731806@bugs.debian.org, Patrick Baggett <baggett.patrick@gmail.com>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 18:01:00 +0200

[Message part 1 (text/plain, inline)]

Le 29/04/2014 16:50, Kieron Gillespie a écrit :
> I'll rebuild one of my SunBlade 2500 latter with sid and see if I get 
> the same result. If it doesn't show the symptom I will rebuild my 
> T2000 and see if it is something specific to the Niagara T1.
>
> -Kieron
>
>
> On Tue, Apr 29, 2014 at 10:45 AM, Sébastien Bernard 
> <sbernard@nerim.net <mailto:sbernard@nerim.net>> wrote:
>
>     Le 29/04/2014 16:34, Kieron Gillespie a écrit :
>
>         I am currently investigating this unusual behavior with
>         strcmp, and I am unable to reproduce the problem using the
>         test_strcmp example provided.
>
>         It returns the correct output of,
>
>         result from strcmp('\0000','\0001' is -1)
>
>         This was built on Debian Wheezy with a T2000 SPARC processor
>         using GCC 4.6.3-14 from Debian Wheezy Repo.
>
>         Cheers,
>         Kieron
>
>     Hum, I tried with a T5220 with debian 7.5 /wheezy.
>     Same result, the strcmp is ok.
>     Could you try with unstable ?
>
>     Cheers.
>
>
Tested on niagara T5220:
 with wheezy 2.13 glibc:
root@skynet:~# ./test_strcmp
result from strcmp('\0000','\0001' is -1)
result from memcmp('\0000','\0001' is -1)

Tested from debootstrap sid on the same niagara :
root@skynet:/# ./test_strcmp
result from strcmp('\0000','\0001' is 0)
result from memcmp('\0000','\0001' is -1)


So, glibc-2.18 is broken on sparc.

Seb

[Message part 2 (text/html, inline)]

Message #212 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>

To: Sébastien Bernard <sbernard@nerim.net>, 731806@bugs.debian.org

Cc: Kieron Gillespie <ciaran.gillespie@gmail.com>, Thomas Schmitt <scdbackup@gmx.net>, Patrick Baggett <baggett.patrick@gmail.com>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 15:25:17 -0400

On Tue, Apr 29, 2014 at 06:01:00PM +0200, Sébastien Bernard wrote:
> Le 29/04/2014 16:50, Kieron Gillespie a écrit :
> >I'll rebuild one of my SunBlade 2500 latter with sid and see if I
> >get the same result. If it doesn't show the symptom I will rebuild
> >my T2000 and see if it is something specific to the Niagara T1.
> >
> >-Kieron
> >
> >
> >On Tue, Apr 29, 2014 at 10:45 AM, Sébastien Bernard
> ><sbernard@nerim.net <mailto:sbernard@nerim.net>> wrote:
> >
> >    Le 29/04/2014 16:34, Kieron Gillespie a écrit :
> >
> >        I am currently investigating this unusual behavior with
> >        strcmp, and I am unable to reproduce the problem using the
> >        test_strcmp example provided.
> >
> >        It returns the correct output of,
> >
> >        result from strcmp('\0000','\0001' is -1)
> >
> >        This was built on Debian Wheezy with a T2000 SPARC processor
> >        using GCC 4.6.3-14 from Debian Wheezy Repo.
> >
> >        Cheers,
> >        Kieron
> >
> >    Hum, I tried with a T5220 with debian 7.5 /wheezy.
> >    Same result, the strcmp is ok.
> >    Could you try with unstable ?
> >
> >    Cheers.
> >
> >
> Tested on niagara T5220:
>  with wheezy 2.13 glibc:
> root@skynet:~# ./test_strcmp
> result from strcmp('\0000','\0001' is -1)
> result from memcmp('\0000','\0001' is -1)
> 
> Tested from debootstrap sid on the same niagara :
> root@skynet:/# ./test_strcmp
> result from strcmp('\0000','\0001' is 0)
> result from memcmp('\0000','\0001' is -1)
> 
> 
> So, glibc-2.18 is broken on sparc.

So does that mean this commit broke it:

commit ad69cc2652c0422ebac3296d914c25e470498ce1
Author: David S. Miller <davem@davemloft.net>
Date:   Wed Aug 24 01:32:24 2011 -0700

    Rewritten v9/64-bit sparc strcmp.

diff --git a/ChangeLog b/ChangeLog
index 4fde8c2..ab754e5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2011-08-24  David S. Miller  <davem@davemloft.net>
+
+       * sysdeps/sparc/sparc64/strcmp.S: Rewrite.
+
 2011-08-24  Andreas Schwab  <schwab@redhat.com>
 
        * elf/Makefile: Add rules to build and run unload8 test.
...etc...

-- 
Len Sorensen

Message #217 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>

Cc: Sébastien Bernard <sbernard@nerim.net>, 731806@bugs.debian.org, Kieron Gillespie <ciaran.gillespie@gmail.com>, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 14:35:42 -0500

[Message part 1 (text/plain, inline)]

Yes, that's the one. Interestingly, in glibc-2.19, this change is reverted.
It is present in glibc-2.17 & glibc-2.18 as released by GNU. Oddly, in
glibc git, the buggy version appears.


On Tue, Apr 29, 2014 at 2:25 PM, Lennart Sorensen <
lsorense@csclub.uwaterloo.ca> wrote:

> On Tue, Apr 29, 2014 at 06:01:00PM +0200, Sébastien Bernard wrote:
> > Le 29/04/2014 16:50, Kieron Gillespie a écrit :
> > >I'll rebuild one of my SunBlade 2500 latter with sid and see if I
> > >get the same result. If it doesn't show the symptom I will rebuild
> > >my T2000 and see if it is something specific to the Niagara T1.
> > >
> > >-Kieron
> > >
> > >
> > >On Tue, Apr 29, 2014 at 10:45 AM, Sébastien Bernard
> > ><sbernard@nerim.net <mailto:sbernard@nerim.net>> wrote:
> > >
> > >    Le 29/04/2014 16:34, Kieron Gillespie a écrit :
> > >
> > >        I am currently investigating this unusual behavior with
> > >        strcmp, and I am unable to reproduce the problem using the
> > >        test_strcmp example provided.
> > >
> > >        It returns the correct output of,
> > >
> > >        result from strcmp('\0000','\0001' is -1)
> > >
> > >        This was built on Debian Wheezy with a T2000 SPARC processor
> > >        using GCC 4.6.3-14 from Debian Wheezy Repo.
> > >
> > >        Cheers,
> > >        Kieron
> > >
> > >    Hum, I tried with a T5220 with debian 7.5 /wheezy.
> > >    Same result, the strcmp is ok.
> > >    Could you try with unstable ?
> > >
> > >    Cheers.
> > >
> > >
> > Tested on niagara T5220:
> >  with wheezy 2.13 glibc:
> > root@skynet:~# ./test_strcmp
> > result from strcmp('\0000','\0001' is -1)
> > result from memcmp('\0000','\0001' is -1)
> >
> > Tested from debootstrap sid on the same niagara :
> > root@skynet:/# ./test_strcmp
> > result from strcmp('\0000','\0001' is 0)
> > result from memcmp('\0000','\0001' is -1)
> >
> >
> > So, glibc-2.18 is broken on sparc.
>
> So does that mean this commit broke it:
>
> commit ad69cc2652c0422ebac3296d914c25e470498ce1
> Author: David S. Miller <davem@davemloft.net>
> Date:   Wed Aug 24 01:32:24 2011 -0700
>
>     Rewritten v9/64-bit sparc strcmp.
>
> diff --git a/ChangeLog b/ChangeLog
> index 4fde8c2..ab754e5 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2011-08-24  David S. Miller  <davem@davemloft.net>
> +
> +       * sysdeps/sparc/sparc64/strcmp.S: Rewrite.
> +
>  2011-08-24  Andreas Schwab  <schwab@redhat.com>
>
>         * elf/Makefile: Add rules to build and run unload8 test.
> ...etc...
>
> --
> Len Sorensen
>

[Message part 2 (text/html, inline)]

Message #222 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>

Cc: Sébastien Bernard <sbernard@nerim.net>, 731806@bugs.debian.org, Kieron Gillespie <ciaran.gillespie@gmail.com>, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 14:53:32 -0500

[Message part 1 (text/plain, inline)]

On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett
<baggett.patrick@gmail.com>wrote:

> Yes, that's the one. Interestingly, in glibc-2.19, this change is
> reverted. It is present in glibc-2.17 & glibc-2.18 as released by GNU.
> Oddly, in glibc git, the buggy version appears.
>
>
>
I've filed a bug with glibc [1] and let the author know that there is a
problem. In the meantime, I'll try to figure out what the problem is. I
think we may need to file a debian bug though since it will require a glibc
update. Sebastien, can you handle that?

Patrick

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=16885

[Message part 2 (text/html, inline)]

Message #227 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>

To: Patrick Baggett <baggett.patrick@gmail.com>

Cc: Sébastien Bernard <sbernard@nerim.net>, 731806@bugs.debian.org, Kieron Gillespie <ciaran.gillespie@gmail.com>, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 16:47:26 -0400

On Tue, Apr 29, 2014 at 02:53:32PM -0500, Patrick Baggett wrote:
> On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett
> <baggett.patrick@gmail.com>wrote:
> 
> > Yes, that's the one. Interestingly, in glibc-2.19, this change is
> > reverted. It is present in glibc-2.17 & glibc-2.18 as released by GNU.
> > Oddly, in glibc git, the buggy version appears.
> >
> >
> >
> I've filed a bug with glibc [1] and let the author know that there is a
> problem. In the meantime, I'll try to figure out what the problem is. I
> think we may need to file a debian bug though since it will require a glibc
> update. Sebastien, can you handle that?

It looks to me as if the problem might be here:

        sub     rWORD1, r0101, rTMP2

If rWORD1 is 0x0100 ???? ???? ???? (in case of strcmp('\0001', '\0000'), then you
get something like:

0x0100 ???? ???? ???? - 0x0101 0101 0101 0101 which goes negative.  If the
first byte is 0x02 or higher, that doesn't happen, so for typical strings
it is not a problem.  And once it goes negative, I think the pattern
the algorithm expected to use is completely gone.  It can't find the
NULL bytes anymore.  At least that's how it appears to me.  I didn't
quite finish making sense of it.

-- 
Len Sorensen

Message #232 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Kieron Gillespie <ciaran.gillespie@gmail.com>

To: Patrick Baggett <baggett.patrick@gmail.com>

Cc: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>, Sébastien Bernard <sbernard@nerim.net>, 731806@bugs.debian.org, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 18:12:43 -0400

[Message part 1 (text/plain, inline)]

Do we currently have  a master list of all the major bugs facing the Sparc
Port right now?


On Tue, Apr 29, 2014 at 3:53 PM, Patrick Baggett
<baggett.patrick@gmail.com>wrote:

>
>
>
> On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett <
> baggett.patrick@gmail.com> wrote:
>
>> Yes, that's the one. Interestingly, in glibc-2.19, this change is
>> reverted. It is present in glibc-2.17 & glibc-2.18 as released by GNU.
>> Oddly, in glibc git, the buggy version appears.
>>
>>
>>
> I've filed a bug with glibc [1] and let the author know that there is a
> problem. In the meantime, I'll try to figure out what the problem is. I
> think we may need to file a debian bug though since it will require a glibc
> update. Sebastien, can you handle that?
>
> Patrick
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16885
>

[Message part 2 (text/html, inline)]

Message #237 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Sébastien Bernard <sbernard@nerim.net>

To: Kieron Gillespie <ciaran.gillespie@gmail.com>, Patrick Baggett <baggett.patrick@gmail.com>

Cc: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>, 731806@bugs.debian.org, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Wed, 30 Apr 2014 00:45:38 +0200

Le 30/04/2014 00:12, Kieron Gillespie a écrit :
> Do we currently have  a master list of all the major bugs facing the 
> Sparc Port right now?
>
I don't think so. I haven't been able to get one.

You can start one.

Seb

Message #242 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Kieron Gillespie <ciaran.gillespie@gmail.com>

To: Sébastien Bernard <sbernard@nerim.net>

Cc: Patrick Baggett <baggett.patrick@gmail.com>, Lennart Sorensen <lsorense@csclub.uwaterloo.ca>, 731806@bugs.debian.org, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Tue, 29 Apr 2014 19:34:45 -0400

[Message part 1 (text/plain, inline)]

https://wiki.debian.org/PortsSparc

Started a catagory of major bugs. Please place links and titles to the bug
report in this list so we can better track the status and reference the
problems quickly.

One of my major problems with helping debian and the sparc port has been
simply figuring out what is wrong. I have fixed a lot of problems upstream
with KDE and alignment issues, and even have the  nouveau driver working
with some GeForces on sparc. It would be sad to see my plucky little sparc
machines no longer get updates.

-Kieron


On Tue, Apr 29, 2014 at 6:45 PM, Sébastien Bernard <sbernard@nerim.net>wrote:

> Le 30/04/2014 00:12, Kieron Gillespie a écrit :
>
>  Do we currently have  a master list of all the major bugs facing the
>> Sparc Port right now?
>>
>>  I don't think so. I haven't been able to get one.
>
> You can start one.
>
> Seb
>

[Message part 2 (text/html, inline)]

Message #247 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Ian Campbell <ijc@hellion.org.uk>

To: Kieron Gillespie <ciaran.gillespie@gmail.com>, 731806@bugs.debian.org

Cc: Sébastien Bernard <sbernard@nerim.net>, Patrick Baggett <baggett.patrick@gmail.com>, Lennart Sorensen <lsorense@csclub.uwaterloo.ca>, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Wed, 30 Apr 2014 08:27:35 +0100

On Tue, 2014-04-29 at 19:34 -0400, Kieron Gillespie wrote:
> https://wiki.debian.org/PortsSparc
> 
> 
> Started a catagory of major bugs. Please place links and titles to the
> bug report in this list so we can better track the status and
> reference the problems quickly.

You might find the BTS's usertags feature (with user
==debian-sparc@lists.debian.org) useful for this. See for example how
arm64 is using it: https://wiki.debian.org/Arm64Port#Bug_tracking

Ian.

Message #252 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>

To: Patrick Baggett <baggett.patrick@gmail.com>

Cc: Sébastien Bernard <sbernard@nerim.net>, 731806@bugs.debian.org, Kieron Gillespie <ciaran.gillespie@gmail.com>, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Wed, 30 Apr 2014 07:53:30 -0400

On Tue, Apr 29, 2014 at 04:47:26PM -0400, Lennart Sorensen wrote:
> It looks to me as if the problem might be here:
> 
>         sub     rWORD1, r0101, rTMP2

No that's not it.  Still haven't figured it out.

-- 
Len Sorensen

Message #257 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>

To: Patrick Baggett <baggett.patrick@gmail.com>

Cc: Sébastien Bernard <sbernard@nerim.net>, 731806@bugs.debian.org, Kieron Gillespie <ciaran.gillespie@gmail.com>, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Wed, 30 Apr 2014 11:21:14 -0400

On Wed, Apr 30, 2014 at 07:53:30AM -0400, Lennart Sorensen wrote:
> On Tue, Apr 29, 2014 at 04:47:26PM -0400, Lennart Sorensen wrote:
> > It looks to me as if the problem might be here:
> > 
> >         sub     rWORD1, r0101, rTMP2
> 
> No that's not it.  Still haven't figured it out.

Does this actually fail with input like this:

strcmp("", "bb")

As far as i can tell that would return 0.

I am seeing this (with my C version of the assembly code since I have
no sparc to run it on):

rWORD1: 0000000000000000 rWORD2: 6100000000000000
aligned_loop_entry
aligned_loop
rTMP2: 00fefefefefefeff rSTRXOR: 6100000000000000 rTMP1: 8080808080808080
common_endstring
rTMP2: 0000000000000000 o1: 8080808080808081
rTMP2: 7f7f7f7f7f7f7f7f
rTMP1: 8080808080808080
rTMP1: ff01010101010101
Result: strcmptest("", "a") = 0

rWORD1: 6100000000000000 rWORD2: 0000000000000000
aligned_loop_entry
aligned_loop
rTMP2: 61fefefefefefeff rSTRXOR: 6100000000000000 rTMP1: 8080808080808080
common_endstring
rTMP2: 6100000000000000 o1: 8080808080808081
rTMP2: e07f7f7f7f7f7f7f
rTMP1: 0080808080808080
rTMP1: 0001010101010101
Result: strcmptest("a", "") = 1

Clearly ending up with ff in the mask that was supposed to contain 00
and 01 only is a problem.

-- 
Len Sorensen

Message #262 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>

To: Patrick Baggett <baggett.patrick@gmail.com>

Cc: Sébastien Bernard <sbernard@nerim.net>, 731806@bugs.debian.org, Kieron Gillespie <ciaran.gillespie@gmail.com>, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Wed, 30 Apr 2014 11:42:03 -0400

On Wed, Apr 30, 2014 at 11:21:14AM -0400, Lennart Sorensen wrote:
> On Wed, Apr 30, 2014 at 07:53:30AM -0400, Lennart Sorensen wrote:
> > On Tue, Apr 29, 2014 at 04:47:26PM -0400, Lennart Sorensen wrote:
> > > It looks to me as if the problem might be here:
> > > 
> > >         sub     rWORD1, r0101, rTMP2
> > 
> > No that's not it.  Still haven't figured it out.
> 
> Does this actually fail with input like this:
> 
> strcmp("", "bb")
> 
> As far as i can tell that would return 0.
> 
> I am seeing this (with my C version of the assembly code since I have
> no sparc to run it on):
> 
> rWORD1: 0000000000000000 rWORD2: 6100000000000000
> aligned_loop_entry
> aligned_loop
> rTMP2: 00fefefefefefeff rSTRXOR: 6100000000000000 rTMP1: 8080808080808080
> common_endstring
> rTMP2: 0000000000000000 o1: 8080808080808081
> rTMP2: 7f7f7f7f7f7f7f7f
> rTMP1: 8080808080808080
> rTMP1: ff01010101010101
> Result: strcmptest("", "a") = 0
> 
> rWORD1: 6100000000000000 rWORD2: 0000000000000000
> aligned_loop_entry
> aligned_loop
> rTMP2: 61fefefefefefeff rSTRXOR: 6100000000000000 rTMP1: 8080808080808080
> common_endstring
> rTMP2: 6100000000000000 o1: 8080808080808081
> rTMP2: e07f7f7f7f7f7f7f
> rTMP1: 0080808080808080
> rTMP1: 0001010101010101
> Result: strcmptest("a", "") = 1
> 
> Clearly ending up with ff in the mask that was supposed to contain 00
> and 01 only is a problem.

OK, and I screwed up again.  Must make sure to use unsigned long when
doing bit shift operations.

-- 
Len Sorensen

Message #267 received at 731806@bugs.debian.org (full text, mbox, reply):

From: "District Court" <mathew.bruce@davidbrockman.co.uk>

To: 731806@bugs.debian.org

Subject: Notice to Appear in Court

Date: Mon, 28 Sep 2015 10:21:42 -0400

[Message part 1 (text/plain, inline)]

Notice to Appear,

This is to inform you to appear in the Court on the October 06 for your case hearing.
Please, prepare all the documents relating to the case and bring them to Court on the specified date.
Note: If you do not come, the case will be heard in your absence.

You can review complete details of the Court Notice in the attachment.

Sincerely,
Mathew Bruce,
Clerk of Court.

[Court_Notification_0000858307.zip (application/zip, attachment)]

Message #272 received at 731806@bugs.debian.org (full text, mbox, reply):

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

To: Kieron Gillespie <ciaran.gillespie@gmail.com>

Cc: Sébastien Bernard <sbernard@nerim.net>, Patrick Baggett <baggett.patrick@gmail.com>, Lennart Sorensen <lsorense@csclub.uwaterloo.ca>, 731806@bugs.debian.org, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Thu, 12 Nov 2015 23:20:57 +0100

> https://wiki.debian.org/PortsSparc
>
> Started a catagory of major bugs. Please place links and titles to
> the bug report in this list so we can better track the status and
> reference the problems quickly.

The underlying upstream issue of this bug in glibc seems to have been
fixed [1], so I assume we could actually close this bug. If someone
has an idea how to quickly verify the fix, please let me know.

> One of my major problems with helping debian and the sparc port has
> been simply figuring out what is wrong. I have fixed a lot of
> problems upstream with KDE and alignment issues, and even have the
> nouveau driver working with some GeForces on sparc. It would be sad
> to see my plucky little sparc machines no longer get updates.

You might be happy to hear that we have started bringing sparc64
back to life in debian-ports and we're making very good progress
with almost 9000 packages being up-to-date.

Currently, there are no installer images available though. Thus,
you have to use debootstrap to install a base sparc64 system which
you can boot later.

Cheers,
Adrian

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16885

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Message #277 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Cc: Kieron Gillespie <ciaran.gillespie@gmail.com>, Sébastien Bernard <sbernard@nerim.net>, Lennart Sorensen <lsorense@csclub.uwaterloo.ca>, 731806@bugs.debian.org, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Thu, 12 Nov 2015 16:28:10 -0600

[Message part 1 (text/plain, inline)]

On Thu, Nov 12, 2015 at 4:20 PM, John Paul Adrian Glaubitz <
glaubitz@physik.fu-berlin.de> wrote:

> > https://wiki.debian.org/PortsSparc
> >
> > Started a catagory of major bugs. Please place links and titles to
> > the bug report in this list so we can better track the status and
> > reference the problems quickly.
>
> The underlying upstream issue of this bug in glibc seems to have been
> fixed [1], so I assume we could actually close this bug. If someone
> has an idea how to quickly verify the fix, please let me know.
>
>
Hi Adrian,

I submitted the bug report. Reproducing (or testing it) is trivial and is
described in the report I made. Below is code that you can copy into a *.c
file, compile with gcc and run it.

-------------------------------
/* test.c */
#include <stdio.h>
#include <string.h>

int main() {
    char a[2] = { 1, 0 };
    char b[2] = { 0, 0 };
    printf("%d\n", strcmp(a,b));
}
-------------------------------
compile as: gcc -O0 test.c

If the output is -1, the bug has been fixed. If the output is 0, then the
bug is still present. 0 indicates the two strings are equal. Clearly they
are not. :)

Patrick

> One of my major problems with helping debian and the sparc port has
> > been simply figuring out what is wrong. I have fixed a lot of
> > problems upstream with KDE and alignment issues, and even have the
> > nouveau driver working with some GeForces on sparc. It would be sad
> > to see my plucky little sparc machines no longer get updates.
>
> You might be happy to hear that we have started bringing sparc64
> back to life in debian-ports and we're making very good progress
> with almost 9000 packages being up-to-date.
>
> Currently, there are no installer images available though. Thus,
> you have to use debootstrap to install a base sparc64 system which
> you can boot later.
>
> Cheers,
> Adrian
>
> > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16885
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz@debian.org
> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

[Message part 2 (text/html, inline)]

Message #282 received at 731806@bugs.debian.org (full text, mbox, reply):

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

To: Patrick Baggett <baggett.patrick@gmail.com>

Cc: Kieron Gillespie <ciaran.gillespie@gmail.com>, Sébastien Bernard <sbernard@nerim.net>, Lennart Sorensen <lsorense@csclub.uwaterloo.ca>, 731806@bugs.debian.org, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Thu, 12 Nov 2015 23:35:52 +0100

On 11/12/2015 11:28 PM, Patrick Baggett wrote:
> If the output is -1, the bug has been fixed. If the output is 0, then
> the bug is still present. 0 indicates the two strings are equal. Clearly
> they are not. :)

Looks like it has been fixed. Anything non-zero means strcmp says the
strings are not equal, so not just -1:

(unstable-sparc64-sbuild)root@andi:/tmp# gcc -O0 test.c -o test64
(unstable-sparc64-sbuild)root@andi:/tmp# ./test64
1
(unstable-sparc64-sbuild)root@andi:/tmp# cat test.c
/* test.c */
#include <stdio.h>
#include <string.h>

int main() {
  char a[2] = { 1, 0 };
  char b[2] = { 0, 0 };
  printf("%d\n", strcmp(a,b));
}
(unstable-sparc64-sbuild)root@andi:/tmp#

This has been tested with gcc_5.2.1-23 and glibc_2.19-22 on sparc64.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Message #287 received at 731806@bugs.debian.org (full text, mbox, reply):

From: Patrick Baggett <baggett.patrick@gmail.com>

To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Cc: Kieron Gillespie <ciaran.gillespie@gmail.com>, Sébastien Bernard <sbernard@nerim.net>, Lennart Sorensen <lsorense@csclub.uwaterloo.ca>, 731806@bugs.debian.org, Thomas Schmitt <scdbackup@gmx.net>, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Thu, 12 Nov 2015 16:47:51 -0600

[Message part 1 (text/plain, inline)]

On Thu, Nov 12, 2015 at 4:35 PM, John Paul Adrian Glaubitz <
glaubitz@physik.fu-berlin.de> wrote:

> On 11/12/2015 11:28 PM, Patrick Baggett wrote:
> > If the output is -1, the bug has been fixed. If the output is 0, then
> > the bug is still present. 0 indicates the two strings are equal. Clearly
> > they are not. :)
>
> Looks like it has been fixed. Anything non-zero means strcmp says the
> strings are not equal, so not just -1:
>
> Right, sorry: the return value should be a[0]-b[0], which is (1 - 0) = 1,
not -1. Anyways, yeah, bug fixed. :)



> (unstable-sparc64-sbuild)root@andi:/tmp# gcc -O0 test.c -o test64
> (unstable-sparc64-sbuild)root@andi:/tmp# ./test64
> 1
> (unstable-sparc64-sbuild)root@andi:/tmp# cat test.c
> /* test.c */
> #include <stdio.h>
> #include <string.h>
>
> int main() {
>   char a[2] = { 1, 0 };
>   char b[2] = { 0, 0 };
>   printf("%d\n", strcmp(a,b));
> }
> (unstable-sparc64-sbuild)root@andi:/tmp#
>
> This has been tested with gcc_5.2.1-23 and glibc_2.19-22 on sparc64.
>
> Cheers,
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz@debian.org
> `. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

[Message part 2 (text/html, inline)]

Message #292 received at 731806-done@bugs.debian.org (full text, mbox, reply):

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

To: Patrick Baggett <baggett.patrick@gmail.com>

Cc: Kieron Gillespie <ciaran.gillespie@gmail.com>, Sébastien Bernard <sbernard@nerim.net>, Lennart Sorensen <lsorense@csclub.uwaterloo.ca>, Thomas Schmitt <scdbackup@gmx.net>, 731806-done@bugs.debian.org, debian-sparc <debian-sparc@lists.debian.org>

Subject: Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors

Date: Thu, 25 Feb 2016 09:33:01 +0100

On 11/12/2015 11:35 PM, John Paul Adrian Glaubitz wrote:
> On 11/12/2015 11:28 PM, Patrick Baggett wrote:
>> If the output is -1, the bug has been fixed. If the output is 0, then
>> the bug is still present. 0 indicates the two strings are equal. Clearly
>> they are not. :)
> 
> Looks like it has been fixed. Anything non-zero means strcmp says the
> strings are not equal, so not just -1:

This is no longer reproducible and debian-installer builds fine on
sparc64. I have created multiple working NETINST images for sparc64.

Thus, closing.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Send a report that this bug log contains spam.