Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
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 - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: 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
Re: 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
>
Re: 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
>
Re: 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-sparc@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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1398842855.23380.102.ca...@dagon.hellion.org.uk
Re: 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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140430115330.gy17...@csclub.uwaterloo.ca
Re: 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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140430152114.ga17...@csclub.uwaterloo.ca
Re: 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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140430154203.gb17...@csclub.uwaterloo.ca
Re: 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-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
Re: 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
Re: 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.
Re: 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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535fbb26.6030...@nerim.net
Re: 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
Re: 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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140429192516.gw17...@csclub.uwaterloo.ca
Re: 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
Re: 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
Re: 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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140429204726.gx17...@csclub.uwaterloo.ca
Re: 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
Re: 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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53602b92.9020...@nerim.net
Re: 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
Re: Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Le 28/04/2014 12:09, Thomas Schmitt a écrit :
Hi,
I tried with the xorriso -as mkisofs command, with no luck.
This command terminates with a SIGBUS no matter of the options I pass on
the command line.
Ouch.
I have no Debian of arch sparc in reach.
I may provide you access to a shell account on my machines if needed.
xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B
... ./tmp/miniiso/cd_tree/
Valgrind on Linux accuses xorriso-1.3.2 of a small memory leak
with such a run, but not of memory problems.
Sparc architecture is extremely picky about alignement. Bad alignement,
yields SIGSEGV whereas intel only do it in the less efficient way.
Seems to me that there an alignment problem with xorriso.
That would rather be a C compiler problem then.
But given the strange error message of genisoimage, this may
well be a local filesystem peculiarity which causes a chain
of bad memory access with more or less random end.
I traced the problem with debugger, here's the catch:
--
(gdb) c
Continuing.
Breakpoint 3, compare_dirs (rr=0x1e1e60, ll=0x1e1e70) at
/home/seb/dev/cdrkit-1.1.11/genisoimage/write.c:652
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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535e2d72.4070...@nerim.net
Re: 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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/22916707656401032...@scdbackup.webframe.org
Re: 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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140428113544.ga30...@einval.com
Re: 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-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
Re: 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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21777670788974871...@scdbackup.webframe.org
Re: 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-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
Re: 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.
Re: 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-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
Re: 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
Re: 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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20365670802973806...@scdbackup.webframe.org
Re: 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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9919670809032917...@scdbackup.webframe.org
Re: 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
Re: 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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5941670806243473...@scdbackup.webframe.org
Re: 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
Re: 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.
Re: 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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/16290670797627595...@scdbackup.webframe.org
Re: 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-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535ea3fc.8010...@oldelvet.org.uk
Re: 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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1987567089955...@scdbackup.webframe.org
Re: 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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535eb924.5070...@nerim.net
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-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131209224418.24637.51617.reportbug@arya
