This is the mail archive of the
mailing list for the Cygwin project.
RE: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
- From: "Polley Christopher W" <PolleyChristopherW at JohnDeere dot com>
- To: "'cygwin at cygwin dot com'" <cygwin at cygwin dot com>
- Date: Tue, 8 Jan 2002 09:26:00 -0600
- Subject: RE: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
- Reply-to: cygwin at cygwin dot com
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"
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:
< 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
< ReleaseResourceLock (LOCK_FD_LIST, READ_LOCK, "not_open");
> ReleaseResourceLock (LOCK_FD_LIST, READ_LOCK, "not open");
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html