Bug 166055

Summary: ldd debug output on ppc is broken / ppc1.fedora.redhat.com is affected
Product: [Fedora] Fedora Reporter: Michael Schwendt <bugs.michael>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-16 16:44:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michael Schwendt 2005-08-16 13:36:49 UTC
Disclaimer in front:
I do not have a ppc machine. This report is purely based on the results
I got from the ppc1.fedora.redhat.com build server again and again.
It is not reproducible at all with i386 or x86_64, neither on my own
machines nor on the Fedora Extras build servers. It may be a component
other than "ldd" causing this.

Description of problem:
Output of "LD_DEBUG=files,bindings ldd -r /some/binary" prints lines
which write into eachother like output buffering is broken.

Since bugzilla probably will damage the following examples, a large
build log is here:
http://buildsys.fedoraproject.org/logs//development/10-abicheck-1.2-8/ppc/build.log

Example:

      5129:	binding file /lib/libc.so.6 [0] to /lib/libc.so.6 [0]: normal symbol
`svcauthdes_stats'      5130:	binding file cat [0] to /lib/libc.so.6 [0]: normal
symbol `__libc_start_main' [GLIBC_2.0]
 [GLIBC_2.0]

Instead of:

      5129:	binding file /lib/libc.so.6 [0] to /lib/libc.so.6 [0]: normal symbol
`svcauthdes_stats' [GLIBC_2.0]
      5130:	binding file cat [0] to /lib/libc.so.6 [0]: normal symbol
`__libc_start_main' [GLIBC_2.0]

Second example:

      5129:	binding file /lib/libc.so.6 [0] to /lib/libc.so.6 [0]: normal symbol
`__key_gendes_LOCAL'      5130:	
      5130:	calling init: /lib/libc.so.6
      5130:	
 [GLIBC_2.1]

Instead of:

      5129:	binding file /lib/libc.so.6 [0] to /lib/libc.so.6 [0]: normal symbol
`__key_gendes_LOCAL' [GLIBC_2.1]
      5130:	
      5130:	calling init: /lib/libc.so.6
      5130:	

As a result, parsing this output from ldd doesn't work reliably.
For instance, Perl receives the same broken lines through a pipe.

Version-Release number of selected component (if applicable):
Rawhide

How reproducible:
Often enough on the ppc build server.

Comment 1 Jakub Jelinek 2005-08-16 16:44:13 UTC
If Perl does this, it is severely broken.
ldd is a shell script, so by running LD_DEBUG=files,bindings ldd -r /some/binary
you get the debug output for the shell, /some/binary and cat at least.
ldd -r because of SELinux runs the program as either
some_env_var_setting /some/binary | cat
or
some_env_var_setting /lib*/ld*so* /some/binary | cat
In any case, /some/binary and cat are running simultaneously and because of
LD_DEBUG=files,bindings are both emitting debug info to stderr.
And as they are writing simultaneously to the same fd, the output is obviously
intermixed.


Comment 2 Michael Schwendt 2005-08-16 17:44:02 UTC
The "abicheck" utility is written in Perl and parses ldd like this. This means
"good bye, abicheck".

Comment 3 Jakub Jelinek 2005-08-16 18:44:53 UTC
No, it just means the "abicheck" utility needs to be fixed, that's all.
E.g. you can run ldd /some/binary, parse its output to find out which
dynamic linker it uses (alternatively find the same using readelf -Wl or some
other way).  Then just run
LD_DEBUG=files,bindings LD_WARN=yes LD_BIND_NOW=yes LD_TRACE_LOADED_OBJECTS=1 \
$ldso /some/binary
where $ldso would be /lib64/ld-linux-x86-64.so.2 etc. as found by the previous
step.
You can actually run even the binary directly with those env options, but that
wouldn't work right if /some/binary was not dynamically linked ELF binary.

BTW, ldd hasn't changed for a long time and the cat there is nothing PPC
specific, just that if you run ldd with LD_DEBUG on UP box you might be lucky
and not see the lines intermixed.

Comment 4 Michael Schwendt 2005-08-16 19:29:58 UTC
Yes, I figured as much already while taking a look at what ldd does.