From: "Ludovic Courtès" <ludo@gnu.org>
To: Leo Famulari <leo@famulari.name>
Cc: vagrant@debian.org,
Christopher Howard <christopher@librehacker.com>,
efraim@flashner.co.il, 74270@debbugs.gnu.org,
Jean-Francois.Guillaume@univ-nantes.fr,
John Kehayias <john.kehayias@protonmail.com>,
74229@debbugs.gnu.org
Subject: bug#74270: u-boot-tools: tests fail
Date: Mon, 18 Nov 2024 00:21:06 +0100 [thread overview]
Message-ID: <87zflxfnvh.fsf@gnu.org> (raw)
In-Reply-To: <ZzAodeH3pgqwq22B@jasmine.lan> (Leo Famulari's message of "Sat, 9 Nov 2024 22:28:53 -0500")
Hi,
Leo Famulari <leo@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@2024.01
sdl2@2.30.1
mesa@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@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 ?? ()
--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.
next prev parent reply other threads:[~2024-11-17 23:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 22:51 bug#74270: u-boot-tools: tests fail Christopher Howard
2024-11-10 3:28 ` Leo Famulari
2024-11-17 23:21 ` Ludovic Courtès [this message]
2024-11-18 12:40 ` bug#74229: " Ludovic Courtès
2024-11-16 17:38 ` bug#74270: Ahmad Jarara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zflxfnvh.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=74229@debbugs.gnu.org \
--cc=74270@debbugs.gnu.org \
--cc=Jean-Francois.Guillaume@univ-nantes.fr \
--cc=christopher@librehacker.com \
--cc=efraim@flashner.co.il \
--cc=john.kehayias@protonmail.com \
--cc=leo@famulari.name \
--cc=vagrant@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).