Bug 516039

+++ This bug was initially created as a clone of Bug #484809 +++

Description of problem:

# ldd /usr/lib/debug/usr/bin/foomatic-combo-xml.debug
/usr/bin/ldd: /usr/lib/debug/usr/bin/foomatic-combo-xml.debug: ^D: bad ELF interpreter: No such file or directory

That's a literal Control-D in the output.

Version-Release number of selected component (if applicable):
glibc-common-2.5-24.ia64
ldd (GNU libc) 2.5

How reproducible:

Try invoking ldd on any debug file that the file command (or eu-readelf)
considers to be a shared entity.  I used foomatic-combo-xml.debug above.

I tried it first on ia64, but was able to reproduce it on i386 easily, as well.


Actual results:
/usr/bin/ldd: /usr/lib/debug/usr/bin/foomatic-combo-xml.debug: ^D: bad ELF interpreter: No such file or directory

Expected results:
Either list the linkage of the shared object, or provide an error
message in the same format as when a statically linked executable
is found (with multiple-file input), like so:

/usr/lib/debug/usr/bin/foomatic-combo-xml.debug: 
     bad ELF interpreter: No such file or directory

The Control-D makes it a bit tricky for any tests that
are invoking ldd on likely targets (ELF entities as detected
by 'file' and/or eu-readelf) to check that all required files
are present (e.g., no unresolved symbols).

Additional information:

# eu-readelf -h /usr/lib/debug/usr/bin/foomatic-combo-xml.debug
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Ident Version:                     1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel IA-64
  Version:                           1 (current)
  Entry point address:               0x40000000000011e0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          49968 (bytes into file)
  Flags:                             0x10
  Size of this header:               64 (bytes)
  Size of program header entries:    56 (bytes)
  Number of program headers entries: 8
  Size of section header entries:    64 (bytes)
  Number of section headers entries: 42
  Section header string table index: 39

# readelf -Wa /usr/lib/debug/usr/bin/foomatic-combo-xml.debug 2>&1 | grep -e '\.dynamic'
readelf: Warning: the .dynamic section is not contained within the dynamic segment
ELF Header:
  [21] .dynamic          NOBITS          600000000000e330 000220 0001e0 10  WA  5   0  8

Comment from Jan Kratochvil (via IRC):
You are right there is a "bug" in ldd - it should not try to intepret NOBITS .dynamic section as it finds random garbage there.  But in fact is is not a Bug as ldd just runs ld.so and this shared libraries printing is done by the executable itself - so it is printed from the runtime information

Workaround (thanks to Jan):
  If you run `eu-readelf -S' and find .dynamic as NOBITS, do not run ldd
on the file, as that would likely trigger this particular problem.

--- Additional comment from jakub on 2009-02-11 05:10:54 EDT ---

The dynamic linker doesn't know that .dynamic is SHT_NOBITS, section header table isn't allocated.  So it would need to be ldd shell script that would run readelf -S first.

--- Additional comment from schwab on 2009-06-25 10:20:49 EDT ---

The message comes from bash, after execve returned with an error.

--- Additional comment from rrakus on 2009-08-04 09:47:42 EDT ---

I can't reproduce it with bash-3.2-24.el5

--- Additional comment from rrakus on 2009-08-06 06:35:24 EDT ---

Now I'm able to reproduce it in RHEL 5.2 with:
bash-3.2-21.el5
glibc-common-2.5-24
foomatic-3.0.2-38.3.el5

--- Additional comment from rrakus on 2009-08-06 09:30:41 EDT ---

Actually there is two bugs.
1) ldd shouldn't try to execute directly /usr/lib/debug/usr/bin/foomatic-combo-xml.debug
2) bash should test if ELF is PROGBITS or NOBITS

I will clone this bug for ldd