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

[Lynn Lin]

Lynn
在 2012-1-14 下午9:49，"Eli Zaretskii" <address@hidden>写道：
>
> > 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
> solution.
>
> 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
> NULL.
>
> 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.
>
Is that fine you send me a patch to me so I can verify it?
Thanks very much!
> 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.
>
> TIA