Package: guix;
Reported by: Christopher Howard <christopher <at> librehacker.com>
Date: Fri, 8 Nov 2024 22:52:02 UTC
Severity: important
Merged with 74229
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Ludovic Courtès <ludo <at> gnu.org> To: Leo Famulari <leo <at> famulari.name> Cc: vagrant <at> debian.org, Christopher Howard <christopher <at> librehacker.com>, efraim <at> flashner.co.il, 74270 <at> debbugs.gnu.org, Jean-Francois.Guillaume <at> univ-nantes.fr, John Kehayias <john.kehayias <at> protonmail.com>, 74229 <at> debbugs.gnu.org Subject: bug#74270: u-boot-tools: tests fail Date: Mon, 18 Nov 2024 00:21:06 +0100
Hi,
Leo Famulari <leo <at> famulari.name> skribis:
> 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:
--8<---------------cut here---------------start------------->8---
$ guix graph --path u-boot-tools mesa
u-boot-tools <at> 2024.01
sdl2 <at> 2.30.1
mesa <at> 24.0.4
--8<---------------cut here---------------end--------------->8---
The failing tests are during the ‘check-x86’ phase:
--8<---------------cut here---------------start------------->8---
============================= 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] ________
--8<---------------cut here---------------end--------------->8---
I got a backtrace from the failing tests:
--8<---------------cut here---------------start------------->8---
$ 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 <at> 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 <at> entry=204) at ../../common/malloc_simple.c:25
#1 malloc_simple (bytes=bytes <at> 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 ?? ()
--8<---------------cut here---------------end--------------->8---
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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.