u-boot-tools-2024.01 fail on check-x86

  • Done
  • quality assurance status badge
Details
4 participants
  • Jean-Francois GUILLAUME
  • janneke
  • Leo Famulari
  • Ludovic Courtès
Owner
unassigned
Submitted by
Jean-Francois GUILLAUME
Severity
important
Merged with
J
J
Jean-Francois GUILLAUME wrote on 6 Nov 16:21 +0100
(address . bug-guix@gnu.org)
085354b58912a6a66dd424ec8f0d53b5@univ-nantes.fr
Hi,

u-boot-tools-2024.01 fail on check-x86 which in turn prevent building
genimage-18-0.00009af which prevent to run guix system image on an up to
date guix machine.

Please find attache the build log.

Best regards,
--
Cordialement,
Jean-François GUILLAUME

Ingénieur Systèmes, Réseaux, Virtualisation
Plateforme Bioinformatique BiRD, GLiCID, Nantes Université, CHU Nantes,
CNRS, Inserm, BioCore, US16, SFR Bonamy, F

tél : 02-28-08-00-57 (320057)
mail: Jean-Francois.Guillaume@univ-nantes.fr

Bâtiment 06, IRS UN - 8 quai Moncousu - BP 70721 - 44007 Nantes Cedex 1
J
J
Jean-Francois GUILLAUME wrote on 6 Nov 17:09 +0100
(address . 74229@debbugs.gnu.org)
84d8d12ee420ddf004c044b15ebe1afe@univ-nantes.fr
Forgot to add the guix describe

Toggle quote (12 lines)
> (channel
> (name 'guix)
> (url "https://git.savannah.gnu.org/git/guix.git")
> (branch "master")
> (commit
> "ba9466481d10992d35f09d010166d616fdb6a637")
> (introduction
> (make-channel-introduction
> "9edb3f66fd807b096b48283debdcddccfea34bad"
> (openpgp-fingerprint
> "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"))))

--
Cordialement,
Jean-François GUILLAUME

Ingénieur Systèmes, Réseaux, Virtualisation
Plateforme Bioinformatique BiRD, GLiCID, Nantes Université, CHU Nantes,
CNRS, Inserm, BioCore, US16, SFR Bonamy, F

tél : 02-28-08-00-57 (320057)
mail: Jean-Francois.Guillaume@univ-nantes.fr

Bâtiment 06, IRS UN - 8 quai Moncousu - BP 70721 - 44007 Nantes Cedex 1
L
L
Leo Famulari wrote on 9 Nov 22:02 +0100
(no subject)
(address . control@debbugs.gnu.org)
Zy_N6bbKGyCmyVJP@jasmine.lan
merge 74270 74229
L
J
J
janneke wrote on 11 Nov 11:04 +0100
(name . Jean-Francois GUILLAUME)(address . Jean-Francois.Guillaume@univ-nantes.fr)
87h68ew0gg.fsf@gnu.org
Jean-Francois GUILLAUME writes:

Hi,

Toggle quote (4 lines)
> u-boot-tools-2024.01 fail on check-x86 which in turn prevent building
> genimage-18-0.00009af which prevent to run guix system image on an up
> to date guix machine.

Yes, I was hit by this too, preventing an update of the hurd-team branch.

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
L
L
Ludovic Courtès wrote on 17 Nov 23:16 +0100
control message for bug #74270
(address . control@debbugs.gnu.org)
87ldxhh5ey.fsf@gnu.org
severity 74270 important
quit
L
L
Ludovic Courtès wrote on 18 Nov 00:21 +0100
Re: bug#74270: u-boot-tools: tests fail
(name . Leo Famulari)(address . leo@famulari.name)
87zflxfnvh.fsf@gnu.org
Hi,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (5 lines)
> I bisected the package build failure. It began with "gnu: mesa: Update
> to 24.2.2."
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e00c621cbbf58a54ca2dd0c7075f154af26bcd54

Interesting. The path to Mesa is:

Toggle snippet (6 lines)
$ guix graph --path u-boot-tools mesa
u-boot-tools@2024.01
sdl2@2.30.1
mesa@24.0.4

The failing tests are during the ‘check-x86’ phase:

Toggle snippet (47 lines)
============================= test session starts ==============================
platform linux -- Python 3.10.7, pytest-7.1.3, pluggy-1.0.0
rootdir: /tmp/guix-build-u-boot-tools-2024.01.drv-0/u-boot-2024.01/test/py, configfile: pytest.ini
plugins: xdist-2.5.0, forked-1.6.0
collected 1041 items / 1032 deselected / 9 selected

test/py/tests/test_help.py E [ 11%]
test/py/tests/test_ofplatdata.py s [ 22%]
test/py/tests/test_spl.py EEEEE [ 77%]
test/py/tests/test_vbe_vpl.py E [ 88%]
test/py/tests/test_vpl.py s [100%]

==================================== ERRORS ====================================
_______________________ ERROR at setup of test_vpl_help ________________________
test/py/conftest.py:409: in u_boot_console
console.ensure_spawned()
test/py/u_boot_console_base.py:423: in ensure_spawned
self.wait_for_boot_prompt(loop_num = loop_num)
test/py/u_boot_console_base.py:163: in wait_for_boot_prompt
m = self.p.expect([pattern_u_boot_spl_signon] +
test/py/u_boot_spawn.py:203: in expect
raise err
test/py/u_boot_spawn.py:195: in expect
c = os.read(self.fd, 1024).decode(errors='replace')
E OSError: [Errno 5] Input/output error
---------------------------- Captured stdout setup -----------------------------
/tpl/u-boot-tpl
______________________ ERROR at setup of test_ut_spl_init ______________________
test/py/u_boot_spawn.py:195: in expect
c = os.read(self.fd, 1024).decode(errors='replace')
E OSError: [Errno 5] Input/output error

During handling of the above exception, another exception occurred:
test/py/conftest.py:409: in u_boot_console
console.ensure_spawned()
test/py/u_boot_console_base.py:423: in ensure_spawned
self.wait_for_boot_prompt(loop_num = loop_num)
test/py/u_boot_console_base.py:163: in wait_for_boot_prompt
m = self.p.expect([pattern_u_boot_spl_signon] +
test/py/u_boot_spawn.py:204: in expect
raise ValueError('U-Boot exited with %s' % info)
E ValueError: U-Boot exited with signal 11 (SIGSEGV)
---------------------------- Captured stdout setup -----------------------------
/tpl/u-boot-tpl
________ ERROR at setup of test_spl[ut_spl_spl_test_image_FIT_EXTERNAL] ________

I got a backtrace from the failing tests:

Toggle snippet (43 lines)
$ gdb /tmp/guix-build-u-boot-tools-2024.01.drv-0/u-boot-2024.01/build-sandbox_vpl/tpl/u-boot-tpl core

[…]

Core was generated by `/tmp/guix-build-u-boot-tools-2024.01.drv-0/u-boot-2024.01/build-sandbox_vpl/tpl'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000406e03 in alloc_simple (align=1, bytes=bytes@entry=204) at ../../common/malloc_simple.c:25
25 addr = ALIGN(gd->malloc_base + gd->malloc_ptr, align);
warning: File "/gnu/store/zzpbp6rr43smwxzvzd4qd317z5j7qblj-gcc-11.4.0-lib/lib/libstdc++.so.6.0.29-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /gnu/store/zzpbp6rr43smwxzvzd4qd317z5j7qblj-gcc-11.4.0-lib/lib/libstdc++.so.6.0.29-gdb.py
line to your configuration file "/home/ludo/.config/gdb/gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/ludo/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) bt
#0 0x0000000000406e03 in alloc_simple (align=1, bytes=bytes@entry=204) at ../../common/malloc_simple.c:25
#1 malloc_simple (bytes=bytes@entry=204) at ../../common/malloc_simple.c:44
#2 0x0000000000406e5e in calloc (nmemb=<optimized out>, elem_size=<optimized out>)
at ../../common/malloc_simple.c:73
#3 0x00007f2b84eb7f2f in llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) ()
from /gnu/store/s9z30wrxafdj11xfzm81hrxd93f07gwh-llvm-for-mesa-18.1.8/lib/libLLVM.so.18.1
#4 0x00007f2b84f6a18f in ?? ()
from /gnu/store/s9z30wrxafdj11xfzm81hrxd93f07gwh-llvm-for-mesa-18.1.8/lib/libLLVM.so.18.1
#5 0x00007f2b84cbf274 in llvm::MachO::TextAPIError::convertToErrorCode() const ()
from /gnu/store/s9z30wrxafdj11xfzm81hrxd93f07gwh-llvm-for-mesa-18.1.8/lib/libLLVM.so.18.1
#6 0x00007f2b8fa12efe in call_init.part ()
from /gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/lib/ld-linux-x86-64.so.2
#7 0x00007f2b8fa12fe6 in _dl_init ()
from /gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/lib/ld-linux-x86-64.so.2
#8 0x00007f2b8fa28bd0 in _dl_start_user ()
from /gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/lib/ld-linux-x86-64.so.2
#9 0x0000000000000004 in ?? ()
#10 0x00007ffeb813c918 in ?? ()
#11 0x00007ffeb813c973 in ?? ()
#12 0x00007ffeb813c976 in ?? ()
#13 0x00007ffeb813c979 in ?? ()
#14 0x0000000000000000 in ?? ()

It would seem that LLVM, during initialization, ends up calling ‘calloc’
as provided by U-Boot itself, which may not be intended, and then things
go wrong.

Should we configure U-Boot with SYS_MALLOC_SIMPLE disabled to avoid the
custom ‘malloc’?

John, Efraim, Vagrant: thoughts? (Where’s the bug tracker of U-Boot?)

Ludo’.

PS: This is blocking all system tests at least.
L
L
Ludovic Courtès wrote on 18 Nov 13:40 +0100
(name . Leo Famulari)(address . leo@famulari.name)
87wmh0emv1.fsf_-_@gnu.org
Hello,

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

Toggle quote (28 lines)
> (gdb) bt
> #0 0x0000000000406e03 in alloc_simple (align=1, bytes=bytes@entry=204) at ../../common/malloc_simple.c:25
> #1 malloc_simple (bytes=bytes@entry=204) at ../../common/malloc_simple.c:44
> #2 0x0000000000406e5e in calloc (nmemb=<optimized out>, elem_size=<optimized out>)
> at ../../common/malloc_simple.c:73
> #3 0x00007f2b84eb7f2f in llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) ()
> from /gnu/store/s9z30wrxafdj11xfzm81hrxd93f07gwh-llvm-for-mesa-18.1.8/lib/libLLVM.so.18.1
> #4 0x00007f2b84f6a18f in ?? ()
> from /gnu/store/s9z30wrxafdj11xfzm81hrxd93f07gwh-llvm-for-mesa-18.1.8/lib/libLLVM.so.18.1
> #5 0x00007f2b84cbf274 in llvm::MachO::TextAPIError::convertToErrorCode() const ()
> from /gnu/store/s9z30wrxafdj11xfzm81hrxd93f07gwh-llvm-for-mesa-18.1.8/lib/libLLVM.so.18.1
> #6 0x00007f2b8fa12efe in call_init.part ()
> from /gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/lib/ld-linux-x86-64.so.2
> #7 0x00007f2b8fa12fe6 in _dl_init ()
> from /gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/lib/ld-linux-x86-64.so.2
> #8 0x00007f2b8fa28bd0 in _dl_start_user ()
> from /gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/lib/ld-linux-x86-64.so.2
> #9 0x0000000000000004 in ?? ()
> #10 0x00007ffeb813c918 in ?? ()
> #11 0x00007ffeb813c973 in ?? ()
> #12 0x00007ffeb813c976 in ?? ()
> #13 0x00007ffeb813c979 in ?? ()
> #14 0x0000000000000000 in ?? ()
>
> It would seem that LLVM, during initialization, ends up calling ‘calloc’
> as provided by U-Boot itself, which may not be intended, and then things
> go wrong.

Fixed in e526b8b11debb184929abd013b7d589c9db245af by changing the
visibility of the ‘calloc’ symbol to “hidden” so other DSOs like
libLLVM*.so don’t end up calling it.

Would be nice to report upstream. Any taker?

Ludo’.
Closed
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 74229
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