[bug #20495] debug version crashes on windows on close(-1)
Additional Item Attachment, bug #20495 (project make): File name: w32clospipe.difSize:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?20495 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #20495] debug version crashes on windows on close(-1)
Update of bug #20495 (project make): Status:None = Fixed Assigned to:None = eliz Open/Closed:Open = Closed Fixed Release:None = CVS ___ Reply to this item at: http://savannah.gnu.org/bugs/?20495 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #20495] debug version crashes on windows on close(-1)
Follow-up Comment #1, bug #20495 (project make):
There seems to be a change within the Microsoft Visual C++ Runtime between
Microsoft Visual Studio .NET (aka 2002) and Microsoft Visual Studio 2005. I
have no access to Microsoft Visual Studio 2003 so I can't prove if this
behavior was introduced earlier.
Microsoft Visual Studio .NETVc7crtsrcclose.c
/* validate file handle */
if ( ((unsigned)fh = (unsigned)_nhandle) ||
!(_osfile(fh) FOPEN) )
{
/* bad file handle, set errno and abort */
errno = EBADF;
_doserrno = 0;
return -1;
}
Microsoft Visual Studio 8VCcrtsrcclose.c
/* validate file handle */
_CHECK_FH_CLEAR_OSSERR_RETURN( fh, EBADF, -1 );
_VALIDATE_CLEAR_OSSERR_RETURN((fh = 0 (unsigned)fh (unsigned)_nhandle),
EBADF, -1);
_VALIDATE_CLEAR_OSSERR_RETURN((_osfile(fh) FOPEN), EBADF, -1);
Anyway, closing the file handle -1 is definitely a bug, which was ignored by
earlier versions of the Microsoft libraries (in fact it was reported by the
return code of close() which is *explicitly* ignored by the caller within
function.c).
Regards, Stefan
___
Reply to this item at:
http://savannah.gnu.org/bugs/?20495
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #20495] debug version crashes on windows on close(-1)
Is there any fix/patch for this? -Gurpreet Caeies-3 wrote: URL: http://savannah.gnu.org/bugs/?20495 Summary: debug version crashes on windows on close(-1) Project: make Submitted by: tstuefe Submitted on: Monday 07/16/2007 at 07:49 Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.81 Operating System: MS Windows Fixed Release: None ___ Details: I build gnumake and run it on windows. When executing a command ($(shell ..), the command executes, but afterwards make crashes because the MS debug C-Runtime detects a close(-1) and throws an error. When debugging, I saw that the offending close was at function.c:1687 /* Close the write side of the pipe. */ (void) close (pipedes[1]); pipedes[1] is -1, pipedes[0] is a valid file handle. A workaround at this point would be a if(pipedes[1]!=-1) close(..) ... When debugging further, I looked at the function windows32_openpipe. What happens is that the child process spawns fine, but the line 1490: pipedes[1] = _open_osfhandle((long) hChildOutWr, O_APPEND); sets pipedes[1] to -1. I actually don't get this coding, but maybe its me. What I don't understand is how the stdin to the child process is supposed to work at all. Parent hands down its own duplicated stdin to the child (see line 1471, hProcess = process_init_fd(hIn, hChildOutWr, hErr); and later on tries to get an OS handle for the write end of the child's stdout pipe (line 1490)? As I said, maybe I simply don't get it. Microsoft's example for stdio-redirection looks different: http://support.microsoft.com/kb/190351 How to spawn console processes with redirected standard handles Best Regards, Thomas Stuefe ___ Reply to this item at: http://savannah.gnu.org/bugs/?20495 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make -- View this message in context: http://www.nabble.com/-bug--20495--debug-version-crashes-on-windows-on-close%28-1%29-tp11610572p19666384.html Sent from the Gnu - Make - Bugs mailing list archive at Nabble.com. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #20495] debug version crashes on windows on close(-1)
URL: http://savannah.gnu.org/bugs/?20495 Summary: debug version crashes on windows on close(-1) Project: make Submitted by: tstuefe Submitted on: Monday 07/16/2007 at 07:49 Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.81 Operating System: MS Windows Fixed Release: None ___ Details: I build gnumake and run it on windows. When executing a command ($(shell ..), the command executes, but afterwards make crashes because the MS debug C-Runtime detects a close(-1) and throws an error. When debugging, I saw that the offending close was at function.c:1687 /* Close the write side of the pipe. */ (void) close (pipedes[1]); pipedes[1] is -1, pipedes[0] is a valid file handle. A workaround at this point would be a if(pipedes[1]!=-1) close(..) ... When debugging further, I looked at the function windows32_openpipe. What happens is that the child process spawns fine, but the line 1490: pipedes[1] = _open_osfhandle((long) hChildOutWr, O_APPEND); sets pipedes[1] to -1. I actually don't get this coding, but maybe its me. What I don't understand is how the stdin to the child process is supposed to work at all. Parent hands down its own duplicated stdin to the child (see line 1471, hProcess = process_init_fd(hIn, hChildOutWr, hErr); and later on tries to get an OS handle for the write end of the child's stdout pipe (line 1490)? As I said, maybe I simply don't get it. Microsoft's example for stdio-redirection looks different: http://support.microsoft.com/kb/190351 How to spawn console processes with redirected standard handles Best Regards, Thomas Stuefe ___ Reply to this item at: http://savannah.gnu.org/bugs/?20495 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
