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/
