[core-updates] mescc-tools tests fail

  • Done
  • quality assurance status badge
Details
2 participants
  • Jan Nieuwenhuizen
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
Merged with
L
L
Ludovic Courtès wrote on 11 Jul 2021 01:56
(address . bug-guix@gnu.org)
87k0lxafl6.fsf@inria.fr
On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’,
mescc-tools fails tests, with generated binaries segfaulting:

Toggle snippet (38 lines)
$ ./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

This is a dependency of the ‘bootstrap-tarballs’ package.

Ludo’.
L
L
Ludovic Courtès wrote on 18 Jul 2021 23:04
(address . 49515@debbugs.gnu.org)(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)
87o8az49ly.fsf@gnu.org
Hi,

Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (16 lines)
> 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

[...]

Toggle quote (2 lines)
> 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@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:

Toggle snippet (24 lines)
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

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’.
L
L
Ludovic Courtès wrote on 18 Jul 2021 23:08
(address . 49515@debbugs.gnu.org)(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)
87im1749fr.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (2 lines)
> I tried backporting it (patch below) but that leads to:

And here’s the patch.
Attachment: mescc-tools-segfault.patch
J
J
Jan Nieuwenhuizen wrote on 19 Jul 2021 06:49
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 49515@debbugs.gnu.org)
87im16j4bo.fsf@gnu.org
Ludovic Courtès writes:

Hello,

Toggle quote (20 lines)
> Ludovic Courtès <ludo@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...

Toggle quote (11 lines)
>> 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@bootstrappable.irc_channel>
> Date: Thu Oct 15 19:12:18 2020 -0400
>
> Fix ELF headers to be more well behaved

[..]

Toggle quote (3 lines)
> 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@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
L
L
Ludovic Courtès wrote on 26 Jul 2021 13:40
(name . Jan Nieuwenhuizen)(address . janneke@gnu.org)(address . 49515@debbugs.gnu.org)
87fsw18fre.fsf@gnu.org
Hi Janneke!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

Toggle quote (18 lines)
>> Ludovic Courtès <ludo@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

[...]

Toggle quote (6 lines)
>> 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’.
L
L
Ludovic Courtès wrote on 26 Jul 2021 13:40
control message for bug #49515
(address . control@debbugs.gnu.org)
87eebl8fr1.fsf@gnu.org
close 49515
quit
J
J
Jan Nieuwenhuizen wrote on 26 Jul 2021 15:43
Re: bug#49515: [core-updates] mescc-tools tests fail
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 49515@debbugs.gnu.org)
87pmv5kx5y.fsf@gnu.org
Ludovic Courtès writes:

Hi Ludo!

Toggle quote (23 lines)
> Jan Nieuwenhuizen <janneke@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.

Toggle quote (5 lines)
> 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@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com| Avatar® http://AvatarAcademy.com
L
L
Ludovic Courtès wrote on 27 Jul 2021 11:43
control message for bug #49515
(address . control@debbugs.gnu.org)
87mtq85by7.fsf@gnu.org
merge 49515 48595
quit
?