[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

Debbugs page

Ludovic Courtès wrote 4 years ago
(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’.
Ludovic Courtès wrote 4 years ago
(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’.
Ludovic Courtès wrote 4 years ago
(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
Jan Nieuwenhuizen wrote 4 years ago
(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
Ludovic Courtès wrote 4 years ago
(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’.
Ludovic Courtès wrote 4 years ago
control message for bug #49515
(address . control@debbugs.gnu.org)
87eebl8fr1.fsf@gnu.org
close 49515
quit
Jan Nieuwenhuizen wrote 4 years ago
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
Ludovic Courtès wrote 4 years ago
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
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help