Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Thu, Nov 12, 2015 at 4:35 PM, John Paul Adrian Glaubitz <
glaub...@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
> #include
>
> 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 - glaub...@debian.org
> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
> 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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Thu, Nov 12, 2015 at 4:20 PM, John Paul Adrian Glaubitz <
glaub...@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
#include
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 - glaub...@debian.org
> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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
#include
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 - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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-sp...@lists.debian.org) useful for this. See for example how arm64 is using it: https://wiki.debian.org/Arm64Port#Bug_tracking Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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: rWORD2: 6100 aligned_loop_entry aligned_loop rTMP2: 00fefefefefefeff rSTRXOR: 6100 rTMP1: 8080808080808080 common_endstring rTMP2: o1: 8080808080808081 rTMP2: 7f7f7f7f7f7f7f7f rTMP1: 8080808080808080 rTMP1: ff01010101010101 Result: strcmptest(, a) = 0 rWORD1: 6100 rWORD2: aligned_loop_entry aligned_loop rTMP2: 61fefefefefefeff rSTRXOR: 6100 rTMP1: 8080808080808080 common_endstring rTMP2: 6100 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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: rWORD2: 6100 aligned_loop_entry aligned_loop rTMP2: 00fefefefefefeff rSTRXOR: 6100 rTMP1: 8080808080808080 common_endstring rTMP2: o1: 8080808080808081 rTMP2: 7f7f7f7f7f7f7f7f rTMP1: 8080808080808080 rTMP1: ff01010101010101 Result: strcmptest(, a) = 0 rWORD1: 6100 rWORD2: aligned_loop_entry aligned_loop rTMP2: 61fefefefefefeff rSTRXOR: 6100 rTMP1: 8080808080808080 common_endstring rTMP2: 6100 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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('\','\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 scdbac...@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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive:
https://lists.debian.org/30925670721203172...@scdbackup.webframe.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 sbern...@nerim.netwrote:
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('\','\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.
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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('\','\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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie
ciaran.gilles...@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('\','\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
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett baggett.patr...@gmail.com
wrote:
On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie
ciaran.gilles...@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('\','\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(0x101), %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 0x33dfaf454393588
g3 0x3dfaf4 4061940
g4 0xf869cbac -127284308
g5 0x28 40
g6 0xfeff 65279
g7 0xf7ff66d0 -134256944
o0 0xdc48 -9144
o1 0xdc50 -9136
o2 0xdd34 -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
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Tue, Apr 29, 2014 at 10:01 AM, Kieron Gillespie
ciaran.gilles...@gmail.com wrote:
On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett
baggett.patr...@gmail.com wrote:
On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie
ciaran.gilles...@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('\','\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(0x101), %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
sllxr8080, 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 0x33dfaf454393588
g3 0x3dfaf4 4061940
g4 0xf869cbac -127284308
g5 0x28 40
g6 0xfeff 65279
g7 0xf7ff66d0 -134256944
o0 0xdc48 -9144
o1 0xdc50 -9136
o2 0xdd34 -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
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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
sbern...@nerim.net mailto:sbern...@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('\','\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('\','\0001' is -1)
result from memcmp('\','\0001' is -1)
Tested from debootstrap sid on the same niagara :
root@skynet:/# ./test_strcmp
result from strcmp('\','\0001' is 0)
result from memcmp('\','\0001' is -1)
So, glibc-2.18 is broken on sparc.
Seb
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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
sbern...@nerim.net mailto:sbern...@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('\','\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('\','\0001' is -1)
result from memcmp('\','\0001' is -1)
Tested from debootstrap sid on the same niagara :
root@skynet:/# ./test_strcmp
result from strcmp('\','\0001' is 0)
result from memcmp('\','\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 da...@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 da...@davemloft.net
+
+ * sysdeps/sparc/sparc64/strcmp.S: Rewrite.
+
2011-08-24 Andreas Schwab sch...@redhat.com
* elf/Makefile: Add rules to build and run unload8 test.
...etc...
--
Len Sorensen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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
lsore...@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
sbern...@nerim.net mailto:sbern...@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('\','\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('\','\0001' is -1)
result from memcmp('\','\0001' is -1)
Tested from debootstrap sid on the same niagara :
root@skynet:/# ./test_strcmp
result from strcmp('\','\0001' is 0)
result from memcmp('\','\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 da...@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 da...@davemloft.net
+
+ * sysdeps/sparc/sparc64/strcmp.S: Rewrite.
+
2011-08-24 Andreas Schwab sch...@redhat.com
* elf/Makefile: Add rules to build and run unload8 test.
...etc...
--
Len Sorensen
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett baggett.patr...@gmail.comwrote: 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
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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.patr...@gmail.comwrote:
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', '\'), 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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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.patr...@gmail.comwrote: On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett baggett.patr...@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
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 sbern...@nerim.netwrote: 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
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Le 28/04/2014 12:09, Thomas Schmitt a écrit :
Hi,
I tried with the xorriso -as mkisofs command, with no luck.
This command terminates with a SIGBUS no matter of the options I pass on
the command line.
Ouch.
I have no Debian of arch sparc in reach.
I may provide you access to a shell account on my machines if needed.
xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B
... ./tmp/miniiso/cd_tree/
Valgrind on Linux accuses xorriso-1.3.2 of a small memory leak
with such a run, but not of memory problems.
Sparc architecture is extremely picky about alignement. Bad alignement,
yields SIGSEGV whereas intel only do it in the less efficient way.
Seems to me that there an alignment problem with xorriso.
That would rather be a C compiler problem then.
But given the strange error message of genisoimage, this may
well be a local filesystem peculiarity which causes a chain
of bad memory access with more or less random end.
I traced the problem with debugger, here's the catch:
--
(gdb) c
Continuing.
Breakpoint 3, compare_dirs (rr=0x1e1e60, ll=0x1e1e70) at
/home/seb/dev/cdrkit-1.1.11/genisoimage/write.c:652
652if ((*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
654if ((*l)-assoc (*l)-assoc == (*r))
(gdb)
644rpnt = (*r)-isorec.name;
(gdb)
645lpnt = (*l)-isorec.name;
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (strcmp(rpnt, lpnt) == 0) {
(gdb) n
661errmsgno(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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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.st...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Le 28/04/2014 13:20, Thomas Schmitt a écrit :
[genisoimage]
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (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.cEOF
#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('\\','\\0001' is %d)\n,result);
exit(0);
}
EOF
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\','\0001' is 0)
--
Here's the same sample from my intel workstation:
--
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\','\0001' is -1)
--
Typicaly, an endianness error.
If I apply this patch on cdrkit:
--- genisoimage/write.c2014-04-28 13:31:28.103571175 +0200
+++ genisoimage/write.c.new2014-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]) {
#ifdefUSE_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-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi,
Sébastien Bernard:
result from strcmp('\','\0001' is 0)
result from strcmp('\','\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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Le 28/04/2014 14:15, Thomas Schmitt a écrit :
Hi,
Sébastien Bernard:
result from strcmp('\','\0001' is 0)
result from strcmp('\','\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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Mon, Apr 28, 2014 at 8:17 AM, Sébastien Bernard sbern...@nerim.netwrote:
Le 28/04/2014 14:15, Thomas Schmitt a écrit :
Hi,
Sébastien Bernard:
result from strcmp('\','\0001' is 0)
result from strcmp('\','\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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive: https://lists.debian.org/535e54ee.6050...@nerim.net
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 \. 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
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Mon, Apr 28, 2014 at 11:25 AM, Sébastien Bernard sbern...@nerim.netwrote: 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 \. 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.
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 PermsStartCyl 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Mon, Apr 28, 2014 at 11:39 AM, Thomas Schmitt scdbac...@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 PermsStartCyl 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/18128670805771551...@scdbackup.webframe.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Mon, Apr 28, 2014 at 12:25 PM, Thomas Schmitt scdbac...@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
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 KR 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 sbern...@nerim.netwrote:
Le 28/04/2014 13:20, Thomas Schmitt a écrit :
[genisoimage]
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (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.cEOF
#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('\\','\\0001' is %d)\n,result);
exit(0);
}
EOF
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\','\0001' is 0)
--
Here's the same sample from my intel workstation:
--
gcc -o test_strcmp test_strcmp.c
./test_strcmp
result from strcmp('\','\0001' is -1)
--
Typicaly, an endianness error.
If I apply this patch on cdrkit:
--- genisoimage/write.c2014-04-28 13:31:28.103571175 +0200
+++ genisoimage/write.c.new2014-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]) {
#ifdefUSE_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-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive: https://lists.debian.org/535e3cf6.3080...@nerim.net
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On Mon, Apr 28, 2014 at 1:20 PM, Thomas Schmitt scdbac...@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 KR 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.
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Cyril Brulebois k...@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-installerarch=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 Description: Digital signature
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 scdbac...@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-installerarch=sparc Nothing changed recently. They've been using tar based chroots for at least 6 months I think. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
On 2014-02-25 17:56, Cyril Brulebois wrote: Cyril Brulebois k...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
[ TL;DR: d-i FTBFS on sparc, what do we do now? ] Thomas Schmitt scdbac...@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-installerarch=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 Description: Digital signature
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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-installerarch=sparcver=20131014stamp=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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
