Created attachment 7101 [details]
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).