Hi Tobias,
tpowa via GNU coreutils Bug Reports <[email protected]> writes:
> while packaging for Arch Linux, this error on checks bumps up:
>
> FAIL test-strerrorname_np (exit status: 139)
>
> Thanks for your attention.
Thanks for the report and the test-suite.log! I see you are on Linux
7.2.
I ran into this on Fedora 44 as well, and it confused me a bit [1] [2].
I'm not 100% certain, but I suspect Fedora needs to rebuild glibc;
likewise for Arch Linux. I'll share my understanding of the issue, and
you can let me know what you think.
Linux 7.2 added a new error number to all architectures named EFTYPE
[3]. This has existed on the BSDs and macOS for a long time. Therefore,
programs such as this test will expect strerrorname_np to return a
string for the error if it is defined. Here is where that test crashes:
$ gnulib-tool --create-testdir --dir testdir1 strerrorname_np
$ cd testdir1
$ ./configure
$ make check
../build-aux/test-driver: line 119: 396693 Segmentation fault (core
dumped) "$@" >> "$log_file" 2>&1
FAIL: test-strerrorname_np
$ gdb ./gltests/test-strerrorname_np
(gdb) run
(gdb) bt
#0 __strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
#1 0x0000000000400ea2 in streq (__s1=<optimized out>, __s2=0x4045d7
"EFTYPE") at ../gllib/string.h:1370
#2 main () at test-strerrorname_np.c:490
(gdb) list test-strerrorname_np.c:488,491
488 /* Mac OS X, FreeBSD, NetBSD, OpenBSD, Minix, Cygwin */
489 #if defined EFTYPE
490 ASSERT (streq (strerrorname_np (EFTYPE), "EFTYPE"));
491 #endif
Gnulib doesn't replace strerrorname_np since it expects it to handle all
of the error numbers supported by the system, as the function is
documented to do [4]. This is true, apparently, until Linux decides to
add an error number that other platforms have historically supported.
The strerrorname_np function, and related functions, use an error list
defined in sysdeps/gnu/errlist.h from glibc. Here is where EFTYPE is
defined:
#ifdef EFTYPE
_S(EFTYPE, N_("Inappropriate file type or format"))
#endif
So, I suspect your glibc was built against Linux 7.1 headers where this
errno isn't defined. Therefore, the error string does not exist, and
strerrorname_np returns a NULL pointer, which is then dereferenced by
the test. Do you know whether that is the case?
Collin
[1]
https://inbox.sourceware.org/libc-alpha/[email protected]/T/#m873e2fbf61fafaec6c9ad226d592d607bcffeecd
[2]
https://inbox.sourceware.org/libc-alpha/[email protected]/T/#m791fba3eaad3ef2f38c813a63dacac715e7325a8
[3]
https://github.com/torvalds/linux/commit/cf1b04aaef8b83f668fac10bfc4d4d76ba6e6fa1
[4] https://manpages.debian.org/testing/manpages-dev/strerrorname_np.3.en.html
