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

[Thomas Stuefe]

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/