GNU bug report logs -
#49515
[core-updates] mescc-tools tests fail
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Sat, 10 Jul 2021 23:57:02 UTC
Severity: normal
Merged with 48595
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49515 in the body.
You can then email your comments to 49515 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#49515
; Package
guix
.
(Sat, 10 Jul 2021 23:57:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ludovic Courtès <ludo <at> gnu.org>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sat, 10 Jul 2021 23:57:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’,
mescc-tools fails tests, with generated binaries segfaulting:
--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix build mescc-tools
[…]
+ . ./sha256.sh
++ set -ex
++ ./bin/get_machine
+ ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian --architecture knight-native -o test/test3/hold
+ '[' amd64 = amd64 ']'
+ ./test/results/test1-binary
+ ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary --exec_enable
test/test1/hello.sh: line 37: 125 Segmentation fault ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1
++ ./bin/get_machine
make: *** [makefile:104: test1-binary] Error 139
make: *** Waiting for unfinished jobs....
+ '[' amd64 = x86 ']'
+ exit 0
+ . ./sha256.sh
++ set -ex
++ ./bin/get_machine
+ '[' amd64 = x86 ']'
+ exit 0
+ ./bin/hex2 -f test/test3/hold --BigEndian --architecture knight-native --BaseAddress 0 -o test/results/test3-binary
+ . ./sha256.sh
++ set -ex
test/test3/hello.sh: line 23: GET_MACHINE_FLAGS: unbound variable
+ '[' '' = 'knight*' ']'
+ exit 0
Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("test" "-j" "4" "PREFIX=/gnu/store/xps0k41ydjl14lx7cnrgclgsi5cnkib7-mescc-tools-0.7.0" "CC=gcc") exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 0.1 seconds
command "make" "test" "-j" "4" "PREFIX=/gnu/store/xps0k41ydjl14lx7cnrgclgsi5cnkib7-mescc-tools-0.7.0" "CC=gcc" failed with status 2
builder for `/gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv' failed with exit code 1
build of /gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv failed
--8<---------------cut here---------------end--------------->8---
This is a dependency of the ‘bootstrap-tarballs’ package.
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#49515
; Package
guix
.
(Sun, 18 Jul 2021 21:05:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 49515 <at> debbugs.gnu.org (full text, mbox):
Hi,
Ludovic Courtès <ludo <at> gnu.org> skribis:
> On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’,
> mescc-tools fails tests, with generated binaries segfaulting:
>
> $ ./pre-inst-env guix build mescc-tools
>
> […]
>
> + . ./sha256.sh
> ++ set -ex
> ++ ./bin/get_machine
> + ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian --architecture knight-native -o test/test3/hold
> + '[' amd64 = amd64 ']'
> + ./test/results/test1-binary
> + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary --exec_enable
> test/test1/hello.sh: line 37: 125 Segmentation fault ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1
[...]
> builder for `/gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv' failed with exit code 1
I found that this upstream commit, which made it in version 1.1.0, fixes
the segfault:
commit e633669dfdf16f503a7d740b9058e343536533b4
Author: nimaje <nimaje <at> bootstrappable.irc_channel>
Date: Thu Oct 15 19:12:18 2020 -0400
Fix ELF headers to be more well behaved
I tried backporting it (patch below) but that leads to:
--8<---------------cut here---------------start------------->8---
test/test2/hello.sh
+ ./bin/M1 -f test/test2/hex.M1 --LittleEndian --Architecture 1 -o test/test2/hold
+ ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian --Architecture 1 --BaseAddress 0x8048000 -o test/results/test2-binary --exec_enable
++ ./bin/get_machine
+ '[' x86_64 = x86_64 ']'
+ ./test/results/test2-binary
+ r=0
+ '[' 0 = 0 ']'
++ sha256sum -c test/test2/proof.answer
sha256sum: WARNING: 1 computed checksum did NOT match
+ out='test/test2/proof: FAILED'
+ '[' 'test/test2/proof: FAILED' = 'test/test2/proof: OK' ']'
+ exit 2
make: *** [makefile:94: test2-binary] Error 2
Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("test" "-j" "1" "PREFIX=/gnu/store/mklrxb6k2a7f1nspm5az1w3pjgfqyx07-mescc-tools-0.5.2-0.bb062b0") exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 0.0 seconds
command "make" "test" "-j" "1" "PREFIX=/gnu/store/mklrxb6k2a7f1nspm5az1w3pjgfqyx07-mescc-tools-0.5.2-0.bb062b0" failed with status 2
builder for `/gnu/store/5pkxsjjhlirznxfblsm8g4x0dq8nlz6g-mescc-tools-0.5.2-0.bb062b0.drv' failed with exit code 1
build of /gnu/store/5pkxsjjhlirznxfblsm8g4x0dq8nlz6g-mescc-tools-0.5.2-0.bb062b0.drv failed
--8<---------------cut here---------------end--------------->8---
Should we upgrade instead? If we do, what’s the potential for breakage?
Should ‘mes-rb5’ be kept on an older version?
WDYT, Janneke? :-)
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#49515
; Package
guix
.
(Sun, 18 Jul 2021 21:09:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 49515 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> skribis:
> I tried backporting it (patch below) but that leads to:
And here’s the patch.
[mescc-tools-segfault.patch (text/x-patch, inline)]
commit e633669dfdf16f503a7d740b9058e343536533b4
Author: nimaje <nimaje <at> bootstrappable.irc_channel>
Date: Thu Oct 15 19:12:18 2020 -0400
Fix ELF headers to be more well behaved
diff --git a/elf_headers/elf32-debug.hex2 b/elf_headers/elf32-debug.hex2
index 667b032..9fe0183 100644
--- a/elf_headers/elf32-debug.hex2
+++ b/elf_headers/elf32-debug.hex2
@@ -33,7 +33,7 @@
01 # e_ident[EI_DATA] Indicating little endianness
01 # e_ident[EI_VERSION] Indicating original elf
-00 # e_ident[EI_OSABI] Set at 0 because none cares
+03 # e_ident[EI_OSABI] Set at 3 because FreeBSD is strict
00 # e_ident[EI_ABIVERSION] See above
00 00 00 00 00 00 00 # e_ident[EI_PAD]
diff --git a/elf_headers/elf32.hex2 b/elf_headers/elf32.hex2
index 45d365c..6432523 100644
--- a/elf_headers/elf32.hex2
+++ b/elf_headers/elf32.hex2
@@ -34,7 +34,7 @@
01 # e_ident[EI_DATA] Indicating little endianness
01 # e_ident[EI_VERSION] Indicating original elf
-00 # e_ident[EI_OSABI] Set at 0 because none cares
+03 # e_ident[EI_OSABI] Set at 3 because FreeBSD is strict
00 # e_ident[EI_ABIVERSION] See above
00 00 00 00 00 00 00 # e_ident[EI_PAD]
diff --git a/elf_headers/elf64.hex2 b/elf_headers/elf64.hex2
index 23d2a4a..6c10442 100644
--- a/elf_headers/elf64.hex2
+++ b/elf_headers/elf64.hex2
@@ -27,7 +27,7 @@
01 ## e_ident[EI_DATA] Indicating little endianness
01 ## e_ident[EI_VERSION] Indicating original elf
-00 ## e_ident[EI_OSABI] Set at 0 because none cares
+03 ## e_ident[EI_OSABI] Set at 3 because FreeBSD is strict
00 ## e_ident[EI_ABIVERSION] See above
00 00 00 00 00 00 00 ## e_ident[EI_PAD]
@@ -53,7 +53,7 @@
## Program Header
:ELF_program_headers
01 00 00 00 ## p_type
-06 00 00 00 ## Flags
+07 00 00 00 ## ph_flags: PF-X|PF-W|PF-R = 7
00 00 00 00 00 00 00 00 ## p_offset
&ELF_base 00 00 00 00 ## p_vaddr
diff --git a/test/test.answers b/test/test.answers
index d449db4..9b366f7 100644
--- a/test/test.answers
+++ b/test/test.answers
@@ -1,12 +1,12 @@
-b5a1dbfb4b9e42f839cd41f704b2d20d67705be5f5214d194d08026006e823a2 test/results/test0-binary
-34cd00306059776d0a1c54dff9d1a4ecb9915fa5b92746b6999c67e535f56b7c test/results/test1-binary
-2505fa977f1eb9b8eb9cc338af6f606fb8341f1e2f341f71b249c50e7af5e0a7 test/results/test10-binary
-e27aa179b47bd21b8a43f460ef11622dcd13767cb515000ae583dc2706b89657 test/results/test11-binary
-1757e43a482f632286933a56d5da1e87d6385366adfa830df363ba6060a12784 test/results/test2-binary
+054359eb2b4e4f75aa212a41f90654b18b1efdde7ba08aac12bd9c21b1a12cf6 test/results/test0-binary
+56c3021ae5d31e1f57552f103e309603636de5ff38948f1be3e810d9ea0e670b test/results/test1-binary
+2027e0c8d6295f041d338a430c5a3d3aae042294e5ba4ad1eb08bed16b147671 test/results/test10-binary
+ce9e76b600fdf67589e9180571bed092e9e091a3bf70dc852facd1b678d9df7b test/results/test11-binary
+7247e7537ef3a83d4c557941bf59a591d6db0688c7a12362af7d14adac238ad4 test/results/test2-binary
2b80849180d5fb3757bcca2471b6337808e5b5ca80b18d93fa82ddef0435b84b test/results/test3-binary
-7db345c74d6ee13f21857f9f9419db2bb0890782923485b05dd9eb29b6436efa test/results/test4-binary
-a7b5c22218bdad3cb8f74a7951fa1425fee5adafdf206420fd020d92b4a13b5e test/results/test5-binary
-7123c8033949312d9325bffe02246bf599463f214eb0b281e7187c7b06818bae test/results/test6-binary
-5992d312f114019d955195d50af25f68c3ab079b1e115ddf31f1aca2431d5dca test/results/test7-binary
+310bea3129335b2cbda70fd591b2cf079b6f7fc19b22f12061a5379ba96dbdae test/results/test4-binary
+1b09d2b8a3848d691d5d5927f80b6acaad57174b7653d88fe07cd1f6f4bd6f3d test/results/test5-binary
+61d70db94077ee71b5522f44344baf3943c02559fb1c3e311cfe2fb6cb652d55 test/results/test6-binary
+5cba7bcb9de863c721613b5fafa17277e9e83336e32c8e7e59ee76d003ed5f29 test/results/test7-binary
a71dc25bcba2a7298b9b9024a7927e215c5081a9ff90a6afa9b583be6c0a7e06 test/results/test8-binary
-b3ec35dc3ce5335ad384b8b2b8b7930aa414014e2bafa61bb6a2b7be8674b88f test/results/test9-binary
+7fb2aa7451ea132a98f3900b140c8eb3d50751aa6adeac23fd2d766fce2635d4 test/results/test9-binary
diff --git a/test/test1/hex0.hex0 b/test/test1/hex0.hex0
index 7060a6d..611a86f 100644
--- a/test/test1/hex0.hex0
+++ b/test/test1/hex0.hex0
@@ -52,7 +52,7 @@ FB 00 60 00 00 00 00 00 ## e_entry Address of the entry point
## Program Header table
01 00 00 00 ## p_type
-06 00 00 00 ## Flags
+07 00 00 00 ## ph_flags: PF-X|PF-W|PF-R = 7
00 00 00 00 00 00 00 00 ## p_offset
00 00 60 00 00 00 00 00 ## p_vaddr
00 00 00 00 00 00 00 00 ## Undefined
diff --git a/test/test1/hex1.hex0 b/test/test1/hex1.hex0
index a0aa3bc..1c6e0bf 100644
--- a/test/test1/hex1.hex0
+++ b/test/test1/hex1.hex0
@@ -38,7 +38,7 @@
## Program Header table
01 00 00 00 # p_type
-06 00 00 00 # Flags
+07 00 00 00 # ph_flags: PF-X|PF-W|PF-R = 7
00 00 00 00 00 00 00 00 # p_offset
00 00 60 00 00 00 00 00 # p_vaddr
00 00 00 00 00 00 00 00 # Undefined
diff --git a/test/test1/proof1.answer b/test/test1/proof1.answer
index 7d3bb85..8c441ba 100644
--- a/test/test1/proof1.answer
+++ b/test/test1/proof1.answer
@@ -1 +1 @@
-4379770c34e718157f856d938f870ad8179b268e5454f9ff272aad4e43265149 test/test1/proof1
+d1172d0456de0ae4d05705fc7d81c424f4a277b7725d449829322ce07224bebf test/test1/proof1
diff --git a/test/test1/proof2.answer b/test/test1/proof2.answer
index 2440710..6edd102 100644
--- a/test/test1/proof2.answer
+++ b/test/test1/proof2.answer
@@ -1 +1 @@
-5ac7c9c6671709682e06153310c112df5b9352af6f6fef93a3370566d28a9a90 test/test1/proof2
+e6b14d3e5935e52a49beff99b766dcd7c842ae2a8d76f4d4c8b10c2d6d146181 test/test1/proof2
diff --git a/test/test2/hex0.hex0 b/test/test2/hex0.hex0
index 126f909..6697221 100644
--- a/test/test2/hex0.hex0
+++ b/test/test2/hex0.hex0
@@ -42,7 +42,7 @@ FB 00 60 00 00 00 00 00 ## e_entry Address of the entry point
## Program Header table
01 00 00 00 ## p_type
-06 00 00 00 ## Flags
+07 00 00 00 ## ph_flags: PF-X|PF-W|PF-R = 7
00 00 00 00 00 00 00 00 ## p_offset
00 00 60 00 00 00 00 00 ## p_vaddr
00 00 00 00 00 00 00 00 ## Undefined
Information forwarded
to
bug-guix <at> gnu.org
:
bug#49515
; Package
guix
.
(Mon, 19 Jul 2021 04:50:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 49515 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès writes:
Hello,
> Ludovic Courtès <ludo <at> gnu.org> skribis:
>
>> On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’,
>> mescc-tools fails tests, with generated binaries segfaulting:
>>
>> $ ./pre-inst-env guix build mescc-tools
>>
>> […]
>>
>> + . ./sha256.sh
>> ++ set -ex
>> ++ ./bin/get_machine
>> + ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian --architecture knight-native -o test/test3/hold
>> + '[' amd64 = amd64 ']'
>> + ./test/results/test1-binary
>> + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary --exec_enable
>> test/test1/hello.sh: line 37: 125 Segmentation fault ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1
>
> [...]
How weird! I wonder what changed...
>> builder for `/gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv' failed with exit code 1
>
> I found that this upstream commit, which made it in version 1.1.0, fixes
> the segfault:
>
> commit e633669dfdf16f503a7d740b9058e343536533b4
> Author: nimaje <nimaje <at> bootstrappable.irc_channel>
> Date: Thu Oct 15 19:12:18 2020 -0400
>
> Fix ELF headers to be more well behaved
[..]
> Should we upgrade instead? If we do, what’s the potential for breakage?
> Should ‘mes-rb5’ be kept on an older version?
We could try that, I really can't tell if upgrading to 1.1.0 creates
a different mes binary.
Greetings,
Janneke
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Information forwarded
to
bug-guix <at> gnu.org
:
bug#49515
; Package
guix
.
(Mon, 26 Jul 2021 11:41:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 49515 <at> debbugs.gnu.org (full text, mbox):
Hi Janneke!
Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:
>> Ludovic Courtès <ludo <at> gnu.org> skribis:
>>
>>> On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’,
>>> mescc-tools fails tests, with generated binaries segfaulting:
>>>
>>> $ ./pre-inst-env guix build mescc-tools
>>>
>>> […]
>>>
>>> + . ./sha256.sh
>>> ++ set -ex
>>> ++ ./bin/get_machine
>>> + ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian --architecture knight-native -o test/test3/hold
>>> + '[' amd64 = amd64 ']'
>>> + ./test/results/test1-binary
>>> + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary --exec_enable
>>> test/test1/hello.sh: line 37: 125 Segmentation fault ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1
[...]
>> Should we upgrade instead? If we do, what’s the potential for breakage?
>> Should ‘mes-rb5’ be kept on an older version?
>
> We could try that, I really can't tell if upgrading to 1.1.0 creates
> a different mes binary.
I took this route and everything went well, and we can now build
‘bootstrap-tarballs’ on x86_64-linux. I ended up doing additional
changes:
e2690a8eb2 gnu: mes-rb5: Remove.
da32015db0 gnu: mes-minimal-stripped: Explicitly disallow references.
5510e1c483 gnu: mes: Remove 0.19.
81096caf7d gnu: mes: Switch to Guile 3.0.
114a9f1f80 gnu: mescc-tools: Update to 1.2.0.
0b9da8b5a2 gnu: m2-planet: Update to 1.8.0.
8b627a7701 gnu: mes-minimal: Remove unused variable.
Removing ‘mes-rb5’ was a bit disheartening but I guess it’d have to be
updated to the current tool versions.
I removed Mes 0.19 because it failed to build with Guile 3.0 and didn’t
appear to be needed any longer.
Let me know if you think I did anything wrong!
Thanks,
Ludo’.
bug closed, send any further explanations to
49515 <at> debbugs.gnu.org and Ludovic Courtès <ludo <at> gnu.org>
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Mon, 26 Jul 2021 11:41:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#49515
; Package
guix
.
(Mon, 26 Jul 2021 13:45:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 49515 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès writes:
Hi Ludo!
> Jan Nieuwenhuizen <janneke <at> gnu.org> skribis:
>
>>> Should we upgrade instead? If we do, what’s the potential for breakage?
>>> Should ‘mes-rb5’ be kept on an older version?
>>
>> We could try that, I really can't tell if upgrading to 1.1.0 creates
>> a different mes binary.
>
> I took this route and everything went well, and we can now build
> ‘bootstrap-tarballs’ on x86_64-linux. I ended up doing additional
> changes:
>
> e2690a8eb2 gnu: mes-rb5: Remove.
> da32015db0 gnu: mes-minimal-stripped: Explicitly disallow references.
> 5510e1c483 gnu: mes: Remove 0.19.
> 81096caf7d gnu: mes: Switch to Guile 3.0.
> 114a9f1f80 gnu: mescc-tools: Update to 1.2.0.
> 0b9da8b5a2 gnu: m2-planet: Update to 1.8.0.
> 8b627a7701 gnu: mes-minimal: Remove unused variable.
> Removing ‘mes-rb5’ was a bit disheartening but I guess it’d have to be
> updated to the current tool versions.
Yeah, a bit sad but OK I guess.
> I removed Mes 0.19 because it failed to build with Guile 3.0 and didn’t
> appear to be needed any longer.
>
> Let me know if you think I did anything wrong!
LGTM!
Greetings,
Janneke
--
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Merged 48595 49515.
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Tue, 27 Jul 2021 09:44:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 24 Aug 2021 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 298 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.