From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24478 invoked by alias); 28 Jun 2013 17:32:16 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 24447 invoked by uid 48); 28 Jun 2013 17:32:11 -0000 From: "licquia at linuxfoundation dot org" To: glibc-bugs@sourceware.org Subject: [Bug stdio/15701] New: freopen() acts oddly when underlying file descriptor is closed Date: Fri, 28 Jun 2013 17:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: stdio X-Bugzilla-Version: 2.16 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: licquia at linuxfoundation dot org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg00230.txt.bz2 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.