[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DuplicateHandle(in) failed (e=6)

From: Eli Zaretskii
Subject: Re: DuplicateHandle(in) failed (e=6)
Date: Sat, 14 Jan 2012 15:49:25 +0200

> From: Lynn Lin <address@hidden>
> Date: Sun, 8 Jan 2012 09:27:16 +0800
> Cc: "address@hidden" <address@hidden>
> Thanks very much for your quick response.
> I am not sure whether I describe this issue well. The third party call the 
> perl script (this perl script call gmake) perl use pipe to capture gmake 
> output .It report the above error
> There is one piece code in makefile.
> DDIRS = $( foreach dir,$(OBJLISTDIR),$(shell cmd.exe /C "md $(dir) 1>NUL 
> 2>NUL)))
> %.bin:... $(DDIRS)
>          command
> If I remove 1>NUL and 2>NUL ,the error go away. But I continue see the error 
> which haven't identified in which makefile code
> Process_easy :  DuplicateHandle(In) failed (e=6)
> processor_easy: failed to launch process failed (e=6)

I moved this discussion here from help-make, as this problem is
specific to the Windows port of GNU Make.

This problem was intermittently reported for the past several years.
It was not solved because no simple reproducible test case was ever
presented which I could use to debug the problem and verify a possible

Now I've succeeded to craft such a test case, which shows at least one
situation where DuplicateHandle fails when Make attempts to launch a
subsidiary program.  But I need help from people who know more than I
do about standard handles in Windows programs.

The situation is very simple: sometimes Make is invoked from other
Windows programs so that GetStdHandle returns NULL for one or more of
the 3 standard handles.  The current code in Make blithely passes that
NULL to DuplicateHandle, which predictably fails, causing the above
error message.

The question is what to do instead of calling DuplicateHandle with

One possibility would be to pass that NULL to the subsidiary
application we invoke via CreateProcess, by leaving the corresponding
slot in pproc->sv_* array at its initial NULL value (see process_easy
and process_init_fd in sub_proc.c).  Could that be a problem on the
subsidiary process's end?  If this won't do any harm, this is the
easiest way out.

Another possibility is to connect the NULL handles to the null device.

Yet another possibility is to create a console and redirect these
handles to that console.  But I think this is too gross, and also will
probably not DTRT, as the application that invoked Make really didn't
mean it to input or output anything.

Any suggestions and ideas are welcome.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]