Skip to content

binary fails to load (_dl_check_map_versions) after patchelf --set-rpath #192

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pespin opened this issue Feb 11, 2020 · 4 comments
Closed

Comments

@pespin
Copy link
Contributor

pespin commented Feb 11, 2020

Original ticket tacking the issue: https://osmocom.org/issues/4389

So, in summary:
I was using patchelf 0.9-1+b1 from debian9 repos, but run into issue #47 with binary "srsue" from srsLTE.git [1]:

$ patchelf --set-rpath /osmo-gsm-tester-srsue/srslte/lib /osmo-gsm-tester-srsue/srslte/bin/srsue
warning: working around a Linux kernel bug by creating a hole of 124461056 bytes in ‘/osmo-gsm-tester-srsue/srslte/bin/srsue’
maximum file size exceeded

so I then went into building/installing a new version of patchelf. I tried with following patchelf versions:

  • 0.9+52 (debian10 patchelf_0.9+52.20180509-1_amd64.deb)
  • 0.10 (last release Download tarball and bult manually)
  • master (from git, 2ba6481)

All of them fix the issue #47 on binary "srsue". However, all those new versions introduce a new bug with another binary generated by srsLTE.git [1] called "srspec". Patching itself seems to be working fine (patchelf doesn't exit with !=0), but afterwards the loader is unable to load the binary:

# ldd /osmo-gsm-tester-srsepc/srslte/bin/srsepc
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != NULL' failed!

This issue doesn't show up with the original patchelf 0.9-1+b1 from debian9 I was using, so it's a regression added at some point after that and yet not fixed last release nor in currentmaster.

[1] https://github.com/srsLTE/srsLTE

@pespin
Copy link
Contributor Author

pespin commented Feb 11, 2020

I attach a diff here of readelf launched against the working binary (patchelf 0.9-1+b1) and the broken binary (master 2ba6481).
diff.log

@pespin
Copy link
Contributor Author

pespin commented Feb 11, 2020

According to git bisect, this is the commit introducing the regression: c4deb5e

$ git bisect start
$ git bisect bad master
$ git bisect good 0.9
$ git bisect run /bin/bash -c "autoreconf -fi && ./configure && make && cp /osmo-gsm-tester-srsepc/srslte/bin/srsepc.orig /osmo-gsm-tester-srsepc/srslte/bin/srsepc &&  src/patchelf --set-rpath /osmo-gsm-tester-srsepc/srslte/lib /osmo-gsm-tester-srsepc/srslte/bin/srsepc && ldd /osmo-gsm-tester-srsepc/srslte/bin/srsepc"

osmocom-gerrit pushed a commit to osmocom/osmo-ci that referenced this issue Feb 14, 2020
Due to [1], we require both debian9 patchelf v0.9 and v0.10 to be
available and used by osmo-gsm-teser depending on the binary to be
patched.

[1] NixOS/patchelf#192
Related: OS#4389
Change-Id: I28825d723b85900fb51cc5b8a9d14c6ef346e667
@ilg-ul
Copy link

ilg-ul commented May 24, 2020

I confirm that the current patchelf (0.10) damages ELFs.

In my use case I need to first remove rpath/runpath and then set if explicitly as rpath. This procedure damaged most of my ELFs, and I had to find workarounds to patchelf, which were tricky and time consuming.

@domenkozar
Copy link
Member

@pespin thanks for bisecting! I'm going to close this in favor of #170 to keep the duplicates down.

rpurdie added a commit to rpurdie/patchelf that referenced this issue Jun 3, 2020
When running patchelf on some existing patchelf'd binaries to change to longer
RPATHS, ldd would report the binaries as invalid. The output of objdump -x on
those libraryies should show the top of the .dynamic section is getting trashed,
something like:

0x600000001 0x0000000000429000
0x335000 0x0000000000335000
0xc740 0x000000000000c740
0x1000 0x0000000000009098
SONAME libglib-2.0.so.0

(which should be RPATH and DT_NEEDED entries)

This was tracked down to the code which injects the PT_LOAD section.

The issue is that if the program headers were previously relocated to the end
of the file which was how patchelf operated previously, the relocation code
wouldn't work properly on a second run as it now assumes they're located after
the elf header. This change forces them back to immediately follow the elf
header which is where the code has made space for them.

Should fix NixOS#170
and NixOS#192

Signed-off-by: Richard Purdie <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants