[Top][All Lists]

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

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

From: Lynn Lin
Subject: Re: DuplicateHandle(in) failed (e=6)
Date: Sun, 15 Jan 2012 08:28:46 +0800

在 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
> 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.

reply via email to

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