bug#74270: u-boot-tools: tests fail

bug#74270: u-boot-tools: tests fail

[Christopher Howard]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

Getting this error today when trying to do a home-reconfigure:

```
build of /gnu/store/m52ndrap435lwim9c7kij3bnls06kpgs-u-boot-tools-2024.01.drv failed
View build log at '/var/log/guix/drvs/m5/2ndrap435lwim9c7kij3bnls06kpgs-u-boot-tools-2024.01.drv.gz'.
cannot build derivation `/gnu/store/kfsbnb13gnxz90w2l9hpj1nvqaa8nbn1-diffoscope-282.drv': 1 dependencies couldn't be built
guix home: error: build of `/gnu/store/kfsbnb13gnxz90w2l9hpj1nvqaa8nbn1-diffoscope-282.drv' failed
```


[-- Attachment #2: 2ndrap435lwim9c7kij3bnls06kpgs-u-boot-tools-2024.01.drv.gz --]
[-- Type: application/octet-stream, Size: 126758 bytes --]

[-- Attachment #3: Type: text/plain, Size: 916 bytes --]

Build log attached.

Here is my system information:

```
christopher@theoden 
------------------- 
OS: Guix System x86_64 
Host: OptiPlex 9020 00 
Kernel: 5.15.167-gnu 
Uptime: 31 days, 8 hours, 43 mins 
Packages: 167 (guix-system), 248 (guix-user) 
Shell: bash 5.1.16 
Resolution: 1920x1080 
DE: GNOME 
Theme: Adwaita [GTK2/3] 
Icons: Adwaita [GTK2/3] 
Terminal: launch-local-em 
CPU: Intel i5-4570 (4) @ 3.600GHz 
GPU: AMD ATI Radeon HD 8490 / R5 235X OEM 
GPU: Intel HD Graphics 
Memory: 4057MiB / 15914MiB 
```

```
Generation 152	Nov 07 2024 06:15:32	(current)
  guix 2a6d964
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 2a6d96425eea57dc6dd48a2bec16743046e32e06
```

-- 
📛 Christopher Howard
🚀 gemini://gem.librehacker.com
🌐 http://gem.librehacker.com

בראשית ברא אלהים את השמים ואת הארץ

bug#74270: u-boot-tools: tests fail

[Leo Famulari]

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

bug#74270:

[Ahmad Jarara]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]

This error shows up for `guix system image $GUIX_SRC/gnu/system/examples/bare-bones.tmpl` (or any guix system invocation I've tried) as well. Downgrading to the revision before the commit mentioned as the cause is a workaround.

[-- Attachment #2: Type: text/html, Size: 378 bytes --]

bug#74270: u-boot-tools: tests fail

[Ludovic Courtès]

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.

bug#74229: bug#74270: u-boot-tools: tests fail

[Ludovic Courtès]

Hello,

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

> (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’.