Control: reassign -1 glibc
Control: retitle -1 glibc-2.40 printf() segfaults on mips64el, powerpc
Control: notforwarded -1
Control: tags -1 - ftbfs
Dear glibc maintainers,
A change introduced in glibc-2.40 seems to have introduced an
I/O-related bug on mips64el and powerpc. With mips64el being an official
architecture, this was made an RC bug.
This bug was discovered by src:libcap2 starting to FTBFS last October
because tests were segfaulting on the aforementioned architectures. The
segfault occurs during calls to printf().
The segfault is reproducible even with the libcap2 version in bookworm.
In a bookworm mips64el container image, I verified that everything was
still fine with glibc-2.39 from snapshots.d.o, and that the breakage
appears with glibc-2.40.
A bisect determined that the breaking commit is:
2a99e23: Use a doubly-linked list for _IO_list_all (bug 27777)
A crude attempt at reverting this commit (crude because it cannot be
reverted cleanly) resolved the issue.
The problem can is easily reproduced in a mips64el container or chroot
where libcap2 is installed:
# libcap2.so is runnable by itself, so we make a copy executable
$ sudo apt-get install libcap2
$ cp /usr/lib/mips*/libcap.so.2.* .
$ chmod +x libcap.so.2.*
# calls usage(), which calls printf(), which segfaults
$ ./libcap.so.2.* --usage
The relevant code [1] is fairly simple: the call to usage() triggers the
segfault on its sole printf(). Interestingly, the call to summary() does
not trigger the segfault on the first printf(), but one of the later
ones.
The breaking commit looks simple enough that this might be an issue with
how the padding for struct _IO_FILE_complete changed. However I don't
have enough background to be confident in this assessment, and I was
hoping that you might be able to pass this on upstream.
Best,
Christian
[1]:
https://web.git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/libcap/execable.c
