This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/15701] New: freopen() acts oddly when underlying file descriptor is closed
- From: "licquia at linuxfoundation dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 28 Jun 2013 17:32:10 +0000
- Subject: [Bug stdio/15701] New: freopen() acts oddly when underlying file descriptor is closed
- Auto-submitted: auto-generated
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.