exec and stdout stream buffer

John Kelly jakelly at shtc.net
Tue Dec 13 19:43:55 UTC 2005


Using ldd with multiple files, such as:

    ldd wget who

produces stdout to the terminal like:

    who:
            libcrypt.so.0 => ...........
            libgcc_s.so.1 => ...........
            ...
    wget:
            libcrypt.so.0 => ...........
            ...

But when I redirect stdout to a file, it looks like this:

            libcrypt.so.0 => ...........
            libgcc_s.so.1 => ...........
            ...
            libcrypt.so.0 => ...........
            ...
    who:
    wget:


Which is not desirable.

This happens because ldd does a printf of the file name and the colon
to stdout, apparently buffered, and then does execle to have ld-uclibc
print the dependencies, which apparently uses _dl_dprintf with a file
descriptor.

I can work around the problem by patching ldd.c to fflush(stdout)
after printing the filename and colon, but I'm wondering if this is a
uclibc stdio bug.  It does not happen when ldd is linked against the
host glibc, it only happens after ldd is linked against uclibc.

Seems like the stream buffer should be flushed automatically at the
time of execle, since the stdout stream handle holding the buffered
data will be unknown to the new process.

>after an exec, the child inherits all open file descriptors, but all
>old streams have become inaccessible

http://linux.about.com/library/cmd/blcmdl3_stdout.htm





More information about the uClibc mailing list