delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2002/01/08/10:26:38

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Server-Uuid: 2d3b7162-db1d-11d3-b8ee-0008c7dfb6f1
Message-ID: <718198F862F1D411B10F0002A50A4DB101A4F0FA@e90wwce3.dx.deere.com>
From: "Polley Christopher W" <PolleyChristopherW AT JohnDeere DOT com>
Reply-to: cygwin AT cygwin DOT com
To: "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Subject: RE: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
Date: Tue, 8 Jan 2002 09:26:00 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 1025D000983300-01-02

I think I've found the cause of this.

I'll summarize the problem, since this is an old thread: 
when a Windows GUI IDE calls gcc or make, the process reports
"fhandler_base::dup: dup(unknown disk file) failed, handle 0, Win32 error 6"
and crashes.

The problem seems to occur when the [non-cygwin] application calls the
windows CreateProcess API function with one or more of the
STARTUPINFO.hStdInput, .hStdOutput, or .hStdError handles set to NULL; and
STARTF_USESTDHANDLES is set in StartupInfo.dwFlags.

The MSDN documentation is silent on the topic of calling CreateProcess with
STARTUPINFO in this state, so I guess this falls under the realm of
"undefined behavior", but at least some windows programs call this function
without hStdInput set.

I've found that in dtable::vfork_child_dup (), where each open fd in the fd
table is dup'ed if it is open, that if a check for a null handle is added,
the problem disappears:

diff cygwin-1.3.6-6/winsup/cygwin/dtable.cc
cygwin-1.3.6-6-orig/winsup/cygwin/dtable.cc
565c565
<     if (not_open (i) || (fds[i]->get_handle() == NULL) )
---
>     if (not_open (i))


Will this break anything else?  (i.e. are there occasions where a valid open
file handle might be 0?)

I've taken a glance at the testsuite directory -- is a successful "make
check" the benchmark?  What other tests should I run?  

BTW, I noticed in the definition of not_open (in dtable.h), that the
ResourceLock is set with the string "not_open" and then released with the
string "not open".  Does this inconsistency matter?  I haven't noted any
effects (good or bad) of changing the second to "not_open" (to match the
function name):
diff cygwin-1.3.6-6/winsup/cygwin/dtable.h
cygwin-1.3.6-6-orig/winsup/cygwin/dtable.h
62c62
<     ReleaseResourceLock (LOCK_FD_LIST, READ_LOCK, "not_open");
---
>     ReleaseResourceLock (LOCK_FD_LIST, READ_LOCK, "not open");


Warm Regards,
Chris




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019