GNU bug report logs - #74270
u-boot-tools: tests fail

Previous Next

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.

Full log

Message #21 received at 74270 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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.
This bug report was last modified 183 days ago.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.