Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
ldd is a bash script that uses the exit status of the dynamic linker invoked with --verify; an exit status of 1 leads to the " not a dynamic executable" report.
The following strace output shows the failed mmap which leads to the exit status of 1 for an executable with an oversize LOAD segment (that mmap failure is presumably related to the segfault reported in bug 1817106).
[root@RHEL1 NPB_sources]# strace -f /lib64/ld-linux-x86-64.so.2 --verify bin/ft.D.x
execve("/lib64/ld-linux-x86-64.so.2", ["/lib64/ld-linux-x86-64.so.2", "--verify", "bin/ft.D.x"], 0x7ffe379d6758 /* 29 vars */) = 0
brk(NULL) = 0x5555559e1000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffea098f140) = -1 EINVAL (Invalid argument)
openat(AT_FDCWD, "bin/ft.D.x", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0P\16@\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=83168, ...}) = 0
getcwd("/root/BZ1815509/NPB_sources", 128) = 28
mmap(0x400000, 36864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x400000
mmap(0x608000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x608000
mmap(0x60a000, 85941318816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
close(3) = 0
exit_group(1) = ?
+++ exited with 1 +++
[root@RHEL1 NPB_sources]#
The 'file' command, on the other hand, recognizes such an executable as dynamically linked.
[root@RHEL1 NPB_sources]# file bin/ft.D.x
bin/ft.D.x: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=7d80b696366eb0d1d1e4980b3eb953520d45614d, with debug_info, not stripped
[root@RHEL1 NPB_sources]#
Perhaps the dynamic linker needs a different exit code for the purpose of reporting mmap failures (in which case ldd would be modified to recognize it).
Jeff,
Thanks for submitting this!
The use of ldd to identify a binary requires being able to map the executable into memory.
Your alternatives to avoid this requirement are to use `file` or even better `eu-elfclassify` (from elfutils).
I'm closing this as a duplicate of bug 1085549 which already calls out this enhancement request.
*** This bug has been marked as a duplicate of bug 1085549 ***
Description of problem: ldd reports "not a dynamic executable" on a dynamic executable with a large LOAD section (larger than system RAM + swap). If you add more swap space, ldd works correctly. For example, the NAS Parallel Benchmark 'ft' has an 85 GB LOAD section when compiled as a "class D" benchmark (*): ~]# readelf -l bin/ft.D.x | grep -A1 -e Type -e LOAD Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align -- LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x0000000000005df8 0x0000000000005df8 R E 0x200000 LOAD 0x0000000000006dc0 0x0000000000606dc0 0x0000000000606dc0 0x00000000000003cc 0x0000001402a18a80 RW 0x200000 ^^^^^^^^^^^^^^^^^^ | +-- = ~85 GB ~]# ldd bin/ft.D.x not a dynamic executable ~]# free -g total used free shared buff/cache available Mem: 45 0 42 0 2 44 Swap: 22 0 22 ~]# fallocate -l 64G swapfile ~]# chmod 600 swapfile ~]# mkswap swapfile Setting up swapspace version 1, size = 64 GiB (68719472640 bytes) no label, UUID=54cc7016-55fa-47e0-acc8-726375c5be5b ~]# swapon swapfile ~]# free -g total used free shared buff/cache available Mem: 45 0 42 0 2 44 Swap: 86 0 86 ~]# ldd bin/ft.D.x linux-vdso.so.1 (0x00007ffd5b9f8000) libgfortran.so.5 => /lib64/libgfortran.so.5 (0x00007fd52b3bb000) libm.so.6 => /lib64/libm.so.6 (0x00007fd52b039000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd52ae21000) libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007fd52abe0000) libc.so.6 => /lib64/libc.so.6 (0x00007fd52a81e000) libz.so.1 => /lib64/libz.so.1 (0x00007fd52a607000) /lib64/ld-linux-x86-64.so.2 (0x00007fd52b838000) Version-Release number of selected component (if applicable): glibc-2.28-101.el8.x86_64 gcc-gfortran-8.3.1-5.el8.x86_64 How reproducible: always Steps to Reproduce: 1. yum -y install gcc-gfortran openmpi openmpi-devel 2. wget https://www.nas.nasa.gov/assets/npb/NPB3.3.1.tar.gz 3. tar xf NPB3.3.1.tar.gz 4. cd NPB3.3.1/NPB3.3-OMP 5. cp config/make.def.template config/make.def 6. sed -i -e 's/f77/gfortran/' \ -e '/^[CF]FLAGS/ s/$/ -mcmodel=medium/' config/make.def 7. make ft CLASS=D 8. ldd bin/ft.D.x Actual results: not a dynamic executable Expected results: list of the linked libraries Additional info: (*) NPB classes: https://www.nas.nasa.gov/publications/npb_problem_sizes.html