FS#56867 - [glibc][systemd] 236.0-2 Inconsistency detected by ld.so on travis-ci.org

Attached to Project: Arch Linux
Opened by Mikkel Oscar Lyderik (moscar) - Tuesday, 26 December 2017, 10:42 GMT
Last edited by Toolybird (Toolybird) - Thursday, 02 February 2023, 05:18 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
freswa (frederik)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:

Me and others are using https://github.com/mikkeloscar/arch-travis to setup a chroot Arch Linux environment when running builds on travis-ci. Since systemd 236.0-2 was released the builds have failed with this error:

Inconsistency detected by ld.so: dl-open.c: 689: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!

(Full log: https://travis-ci.org/mikkeloscar/arch-travis/jobs/320383646#L721)

When running commands like pacman or curl.

Pinning systemd to the version of the latest Arch ISO (2017.12.01) (systemd 235.38-2) (https://github.com/mikkeloscar/arch-travis/pull/34), solves the problem, but I suspect there is something wrong with the latest systemd package since this happens. I have not seen any issues with my other "real" Arch Linux systems since upgrading to systemd 236.0-2 though.


This is maybe a bit far fetched but when looking into the issue I found that glibc was build with debug symbols at some point (https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/glibc&id=629ac2aea21fb8bcabcf5974251d2335313619fe) Could it be that the latest systemd package is built against a glibc not in the repos?


Additional info:
* systemd 236.0-2


Steps to reproduce:

Setup arch-travis build with this .travis.yml: https://raw.githubusercontent.com/mikkeloscar/arch-travis/broken-systemd/.travis.yml
This task depends upon

Closed by  Toolybird (Toolybird)
Thursday, 02 February 2023, 05:18 GMT
Reason for closing:  None
Additional comments about closing:  See comments
Comment by Bartłomiej Piotrowski (Barthalion) - Wednesday, 27 December 2017, 09:11 GMT
For the record, the glibc commit you mention is just a change to PKGBUILD, it doesn't mean that a package has been built and released.
Comment by Christian Hesse (eworm) - Thursday, 28 December 2017, 19:57 GMT
You can get info about build-time installed package from .BUILDINFO: systemd 236.0-2 was built with glibc 2.26-8 installed.
I do build all my packages in clean chroot. ;)

Any info about systemd 236.0-1? I guess that fails as well?

Neither pacman nor curl are linked against systemd libraries, so no clue what goes wrong here...
Comment by Christian Hesse (eworm) - Thursday, 28 December 2017, 19:58 GMT
Just a guess... Possibly related to any libnss library?
Comment by Matt Kunkel (pilotmattk) - Sunday, 14 January 2018, 03:54 GMT
I'm seeing this same error when compiling lede/openwrt. The exact same build worked in November.
Comment by Christian Hesse (eworm) - Monday, 15 January 2018, 17:47 GMT
I can't reproduce here, so anybody has to do some testing...

Given that libnss libraries are candidates for the issue: Anybody wants to build systemd with reverted b4b36f4405b7fba0deb2a0d6b5379e7ef66e5c61 [0] and try with that?

If that does not help... Bisecting this would be a good idea.

[0] https://github.com/systemd/systemd/commit/b4b36f4405b7fba0deb2a0d6b5379e7ef66e5c61
Comment by Luca Weiss (z3ntu) - Friday, 20 July 2018, 09:18 GMT
I get the error message listed in  FS#57115  (which was marked as a duplicate of this bug) when I try to launch kdevelop.

$ kdevelop
Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 540: elf_machine_rela_relative: Assertion `ELFW(R_TYPE) (reloc->r_info) == R_X86_64_RELATIVE' failed!

EDIT: After rebooting (and also updating my kernel from 4.17.5-1 to 4.17.6-1 it works again...
Comment by Dave Reisner (falconindy) - Monday, 07 January 2019, 11:27 GMT
Is this still a problem?
Comment by Florian Pritz (bluewind) - Wednesday, 23 October 2019, 14:43 GMT
I'm just now seeing this on my laptop in the initrd when trying to run "lvm" after a system upgrade.

EDIT: The error I'm seeing is: Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 540: elf_machine_rela_relative: Assertion `ELFW(R_TYPE) (reloc->r_info) == R_X86_64_RELATIVE' failed!
Comment by Florian Pritz (bluewind) - Wednesday, 23 October 2019, 14:55 GMT
Aaaand reinstalling glibc, systemd, lvm2 + rebuilding the initrd fixed the problem. Before that it was reproducible across reboots. No idea what fixed it and sadly I totally forgot to save a copy of the initrd to diff :(

Feel free to ignore this again since I have no idea what happened. Could be cosmic rays or whatever...
Comment by Florian Pritz (bluewind) - Wednesday, 23 October 2019, 15:15 GMT
Interesting. I am also hitting this problem with many other tools/libraries. One of them being libasound.so I've attached a tarball with the good and bad files and a diffoscope diff. I'm not sure what to make of this. The problem went away after reinstalling the exact same package I installed back in August. Any ideas what happened here?
Comment by Toolybird (Toolybird) - Monday, 02 January 2023, 00:00 GMT
I'm putting this one down to binutils/toolchain flakiness back in the day. Haven't seen any recent reports. Unless someone can repro with current tools I will close the ticket soon..

$ eu-elflint --gnu-ld libasound.so.2.0.0-good
No errors
$ eu-elflint --gnu-ld libasound.so.2.0.0-broken
section [ 8] '.rela.dyn': relocation 1072: invalid type
section [ 8] '.rela.dyn': relocation 1072: invalid symbol index

Loading...