[Bug stdio/15701] New: freopen() acts oddly when underlying file descriptor is closed

["licquia at linuxfoundation dot org" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15701

            Bug ID: 15701
           Summary: freopen() acts oddly when underlying file descriptor
                    is closed
           Product: glibc
           Version: 2.16
            Status: NEW
          Severity: normal
          Priority: P2
         Component: stdio
          Assignee: unassigned at sourceware dot org
          Reporter: licquia at linuxfoundation dot org

Created attachment 7101
  --> http://sourceware.org/bugzilla/attachment.cgi?id=7101&action=edit
test program demonstrating the bug

When the file descriptor underlying a file handle is closed, freopen() exhibits
odd and incorrect behavior.

This is related, I think to the problem mentioned in bug 15589, and is probably
caused by the same commit:

http://repo.or.cz/w/glibc.git/commit/94b7cc3711b0b74c1d3ae18b9a2e019e51a8e0bf

I've attached a test program which shows the behavior specifically when used
with stdin.  Run transcript:

[licquia@lflap5 freopen]$
LD_PRELOAD=../glibc-build/libc.so:../glibc-build/nptl/libpthread.so:../glibc-build/math/libm.so
../glibc-build/elf/ld.so ./freopen-test freopen-test.c
[licquia@lflap5 freopen]$
LD_PRELOAD=../glibc-build/libc.so:../glibc-build/nptl/libpthread.so:../glibc-build/math/libm.so
../glibc-build/elf/ld.so ./freopen-test /dev/zero
[licquia@lflap5 freopen]$
LD_PRELOAD=../glibc-build/libc.so:../glibc-build/nptl/libpthread.so:../glibc-build/math/libm.so
../glibc-build/elf/ld.so ./freopen-test nonexistent-file
could not freopen: No such file or directory
[licquia@lflap5 freopen]$ ./freopen-test freopen-test.c
could not read from freopen-ed stdin
[licquia@lflap5 freopen]$ ./freopen-test /dev/zero
could not read from freopen-ed stdin
[licquia@lflap5 freopen]$ ./freopen-test nonexistent-file
could not freopen: Bad file descriptor
[licquia@lflap5 freopen]$ 

In this case, ../glibc-build contains a build of glibc 2.13, which does not
exhibit the bug.  freopen() works in this case, the resulting file handle is
useful, and unrelated errors (like missing files) are reported properly.

The simple runs at the end are on a Fedora 18 system running
glibc-2.16-31.fc18.x86_64.  As you can see, the freopen calls succeed, but the
resulting file handle is unusable, and the error for a nonexistent file is
mis-reported.

I've verified that the behavior is identical with git HEAD (specifically,
commit fe114d206479a36369d732ea260e81a686fdbb0b).

-- 
You are receiving this mail because:
You are on the CC list for the bug.