Re: [PATCH 3/4] mingw: spawned processes need to inherit only standard handles

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 30, 2019, 22:10 UTC
Message-ID: <nycvar.QRO.7.76.6.1911302308580.31080@tvgsbejvaqbjf.bet>
In-Reply-To: <653e0604-3fd0-235d-564e-8f8a5900a0ae@kdbg.org>

Hi Hannes,

On Fri, 29 Nov 2019, Johannes Sixt wrote:

Show 26 quoted lines

> Am 29.11.19 um 14:52 schrieb Johannes Schindelin:
> > On Thu, 28 Nov 2019, Johannes Sixt wrote:
> >> Am 22.11.19 um 15:41 schrieb Johannes Schindelin via GitGitGadget:
> >>> +		    !getenv("SUPPRESS_HANDLE_INHERITANCE_WARNING")) {
> >>
> >> ... and the variable isn't set, so we continue here. (But I don't think
> >> it is important.)
>
> It's actually not that unimportant because ...
>
> >>
> >>> +			DWORD fl = 0;
> >>> +			int i;
> >>> +
> >>> +			setenv("SUPPRESS_HANDLE_INHERITANCE_WARNING", "1", 1);
> >>> +
> >>> +			for (i = 0; i < stdhandles_count; i++) {
> >>> +				HANDLE h = stdhandles[i];
> >>> +				strbuf_addf(&buf, "handle #%d: %p (type %lx, "
> >>> +					    "handle info (%d) %lx\n", i, h,
> >>> +					    GetFileType(h),
> >>> +					    GetHandleInformation(h, &fl),
> >>> +					    fl);
>
> ... ERANGE happens here in the second iteration, in particular, when
> strbuf_vaddf needs to grow the buffer. vsnprintf generates it.

Ooops. I meant to ask you about using `NO_GETTEXT` in _this_ context. I could imagine that gettext's `vsnprintf()` version behaves at least slightly differently here, and probably different enough to cause an `ERANGE` in your setup but not in mine.

Ciao, Dscho

Show 12 quoted lines

> >>> +			}
> >>> +			strbuf_addstr(&buf, "\nThis is a bug; please report it "
> >>> +				      "at\nhttps://github.com/git-for-windows/"
> >>> +				      "git/issues/new\n\n"
> >>> +				      "To suppress this warning, please set "
> >>> +				      "the environment variable\n\n"
> >>> +				      "\tSUPPRESS_HANDLE_INHERITANCE_WARNING=1"
> >>> +				      "\n");
> >>> +		}
>
> -- Hannes
>