bugmake - Bugs: bug #20495, debug version crashes on windows...


bug #20495: debug version crashes on windows on close(-1)

Submitter:  Thomas Stuefe <tstuefe>
Submitted:  Mon 16 Jul 2007 07:49:06 AM UTC
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  eliz Open/Closed:  Closed
Component Version:  3.81 Operating System:  MS Windows
Fixed Release:  3.82 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Sat 07 Mar 2009 05:34:39 PM UTC, comment #2: 

Thank you for your report.  I fixed this bug in CVS with the attached patch.

Eli Zaretskii <eliz>
Group Member
Tue 03 Mar 2009 04:16:54 PM UTC, comment #1: 

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 .NET\Vc7\crt\src\close.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 8\VC\crt\src\close.c

/* validate file handle */
_VALIDATE_CLEAR_OSSERR_RETURN((fh >= 0 && (unsigned)fh < (unsigned)_nhandle), 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

Mon 16 Jul 2007 07:49:06 AM UTC, original submission:  

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
      /* 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,
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:

"How to spawn console processes with redirected standard handles"

Best Regards,

Thomas Stuefe

Thomas Stuefe <tstuefe>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #17613:  w32clospipe.dif added by eliz (536B - application/vnd.ms-excel)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by psmith (Updated the item)
  • -email is unavailable- added by eliz (Posted a comment)
  • -email is unavailable- added by tstuefe (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-28 psmith Fixed Release4.0 3.82
    2009-03-07 psmith StatusNone Fixed
        Assigned toNone eliz
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.0
    2009-03-07 eliz Attached File- Added w32clospipe.dif, #17613
    2007-07-16 tstuefe Carbon-Copy- Added tstuefe

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code