Bug#1004577: ldconfig -p coredumps

[Christoph Berg]

Package: libc-bin
Version: 2.33-3
Severity: important

In https://salsa.debian.org/python-team/packages/python-telethon/-/jobs/2413916
there is a diff generated between the two builds because a core file
from `ldconfig -p` appears as /usr/lib/python3.10/dist-packages/core.

Backtrace:

[0] 18:56 my...@sid-amd64.maxwell:~/de/py/debian/output/reprotest 1j $ gdb /sbin/ldconfig core
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /sbin/ldconfig...
Reading symbols from /usr/lib/debug/.build-id/f3/4bf815c30c307353fa1703469d5f1f4b3c9356.debug...
[New LWP 12315]
Core was generated by `/sbin/ldconfig -p'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f205bb9f621 in ?? ()
(gdb) bt
#0 0x00007f205bb9f621 in ?? ()
#1 0x0000000000000000 in ?? ()

The build artifacts are available from the salsa page; I don't have
any access to the system there.

There is another ldconfig segfault reported in #806911, I don't
know if that is related.

Christoph

[Aurelien Jarno]

control: severity -1 minor
control: retitle -1 libc-bin: ldconfig aborts when using linux 2.6 personality
control: found -1 glibc/2.26-1

This just points to the code that exit with SIGABRT. This happens
because in that job ldconfig is run with the linux 2.6 personality
(using setarch --uname-2.6) while the minimum supported kernel version
is 3.2 since stretch. This is what happens in practice:

$ setarch --uname-2.6 /sbin/ldconfig
FATAL: kernel too old
Aborted

This only happens for static binaries like ldconfig which get the faked
kernel version through uname, while dynamically linked binaries are able
to get the real kernel version from the ELF auxiliary vectors.

> The build artifacts are available from the salsa page; I don't have
> any access to the system there.
>
> There is another ldconfig segfault reported in #806911, I don't
> know if that is related.

It's related in the sense that they both try to use the linux 2.6
personality to test for reproductible builds. That said in the case of
#806911 ldconfig crashed with a segmentation fault, and that bug got
fixed in the meantime (I just realized that now and closed the bug),
while in your case it exits properly with an abort.

I do believe it's actually a minor issue, we ship > 3.x kernels since
Wheezy, so support for the 2.6 personality is now rather pointless.

Regards,
Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://www.aurel32.net

[Florian Weimer]

* Christoph Berg:

> Package: libc-bin
> Version: 2.33-3
> Severity: important
>
> In https://salsa.debian.org/python-team/packages/python-telethon/-/jobs/2413916
> there is a diff generated between the two builds because a core file
> from `ldconfig -p` appears as /usr/lib/python3.10/dist-packages/core.

Is this the “FATAL: kernel too old” error?

We could remove this check from upstream, and just try to run code and
see how far we get. I assume that these days, the check does more harm
than good. People with pre-3.2 kernels (glibc's built-in baseline) will
likely run a heavily patched 2.6.32 kernel, and that should be *almost*
there.

Thanks,
Florian

[Christoph Berg]

Re: Florian Weimer

> > Package: libc-bin
> > Version: 2.33-3
> > Severity: important
> >
> > In https://salsa.debian.org/python-team/packages/python-telethon/-/jobs/2413916
> > there is a diff generated between the two builds because a core file
> > from `ldconfig -p` appears as /usr/lib/python3.10/dist-packages/core.
>
> Is this the “FATAL: kernel too old” error?

I guess it is, yes.

> We could remove this check from upstream, and just try to run code and
> see how far we get. I assume that these days, the check does more harm
> than good. People with pre-3.2 kernels (glibc's built-in baseline) will
> likely run a heavily patched 2.6.32 kernel, and that should be *almost*
> there.

That would fix the problem, yes.

Christoph