[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
?
Your comment

This issue is archived.

To comment on this conversation send an email to 49515@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 49515
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch