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 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 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
> 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
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
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 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 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
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 wrote: > Le 30/04/2014 00:12, Kieron Gillespie a écrit : > > Do we currently have a master list of all the major bugs facing the >> Sparc Port right now? >> >> I don't think so. I haven't been able to get one. > > You can start one. > > Seb >
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
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 wrote: > > > > 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
On Tue, Apr 29, 2014 at 02:53:32PM -0500, Patrick Baggett wrote: > On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett > wrote: > > > Yes, that's the one. Interestingly, in glibc-2.19, this change is > > reverted. It is present in glibc-2.17 & glibc-2.18 as released by GNU. > > Oddly, in glibc git, the buggy version appears. > > > > > > > I've filed a bug with glibc [1] and let the author know that there is a > problem. In the meantime, I'll try to figure out what the problem is. I > think we may need to file a debian bug though since it will require a glibc > update. Sebastien, can you handle that? It looks to me as if the problem might be here: sub rWORD1, r0101, rTMP2 If rWORD1 is 0x0100 (in case of strcmp('\0001', '\'), 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
On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett 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
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 > > >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 > 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 > + > + * sysdeps/sparc/sparc64/strcmp.S: Rewrite. > + > 2011-08-24 Andreas Schwab > > * 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 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 > >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 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 + + * sysdeps/sparc/sparc64/strcmp.S: Rewrite. + 2011-08-24 Andreas Schwab * 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
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 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 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 >0xf7ebd30c <+12>:or %g1, 0x101, %g1 >0xf7ebd310 <+16>:andcc %o1, 7, %g3 >0xf7ebd314 <+20>:bne,pn %icc, 0xf7ebd4e4 >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 > >
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
On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett 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 0xf7ebd30c <+12>:or %g1, 0x101, %g1 0xf7ebd310 <+16>:andcc %o1, 7, %g3 0xf7ebd314 <+20>:bne,pn %icc, 0xf7ebd4e4 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
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 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. > >
Re: 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
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 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
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
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-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535ebef8.9010...@nerim.net
Re: 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-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535ebea3.4030...@nerim.net
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
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
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, > 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
On Mon, Apr 28, 2014 at 1:20 PM, Thomas Schmitt wrote: > Hi, > > > I really need a disassembly and to be able to probe the runtime > It's the job of a C union to provide a common hull around objects > of different size. One may dispute whether using union is a good > idea (like overloading in the OO paradigm). But unions are part of C > since K&R and they are supposed to be safe. > > http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Size-of-Unions No, it's plain wrong. Unions are fine, if used properly. You aren't using them properly. Let me show you how by a more extreme example: #include 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
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 wrote: > 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.c< #include > #include > > 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, > I really need a disassembly and to be able to probe the runtime > stack a bit, so that really means that I need to build the code. :) The current example would be a bit too opulent, i guess: -rwxr-xr-x 1 thomas thomas 3753398 avril 28 17:49 xorriso/xorriso (wget http://www.gnu.org/software/xorriso/xorriso-1.3.2.tar.gz untar, cd xorriso-1.3.2, ./configure, make, ls -l xorriso/xorriso, crash by: xorriso/xorriso -outdev stdio:/dev/null -map ./xorriso / ) I'll try to reproduce by a smaller program on Sebastien's system. > I think as a more meta-problem is this: the code's logic for "how > much" to copy is wrong. It copies too many bytes on many cases and > violates the C contract that you'll only copy like objects using "=". > [...] you're copying unlike objects of different sizes and > that's never safe. It's the job of a C union to provide a common hull around objects of different size. One may dispute whether using union is a good idea (like overloading in the OO paradigm). But unions are part of C since K&R and they are supposed to be safe. http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Size-of-Unions As for the cost: The threads are running big operations of libburn. Even a full MB of copying would not make much difference. Elsewise i agree with you. I would have written it differently, too. But i will try to keep the necessary changes as small as possible. So the union approach will most probably stay unless i get convinced that it is faulty C language. Have a nice day :) Thomas -- 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
On Mon, Apr 28, 2014 at 12:25 PM, Thomas Schmitt 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 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
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
On Mon, Apr 28, 2014 at 11:39 AM, Thomas Schmitt 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, 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:25 AM, Sébastien Bernard wrote: > Le 28/04/2014 16:05, Patrick Baggett a écrit : > > strcmp() may well be implemented by word comparisons. But then it > >> is the duty of the implementation to properly handle the ends of >>> the strings even if those are not word aligned. >>> >> Indeed, the correct fix is using strcmp. Meanwhile, the package is >> broken. >> >> > Wow, that's pretty bad. How did that slip? Also, are you building 64-bit > or 32-bit code, and what CPU architecture (perhaps some per-CPU > implementation is buggy but not others?) This information will help when > tracking down the issue. > > I think this happens in this particular case comparing \000x and \. > 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
On Mon, Apr 28, 2014 at 8:17 AM, Sébastien Bernard wrote: > 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 > >
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
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 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.c< #include 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 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
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
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' }, 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' }, 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 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-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/24331670761945484...@scdbackup.webframe.org
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-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535e16c5.4070...@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-installer&arch=sparc&ver=20131014&stamp=1381835153 I can't tell for sure since it's been a while but I think I was unable to reproduce it on a porterbox. Probably some FS-dependent fun? Anyone would have a clue about it? Thanks for your time. Mraw, KiBi. -- 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