PATH variable grows each time compiler is run

[brson]

Trying to turn on windows tests (#16457) I'm now hitting errors like

---- path::GenericPath::set_extension_0 stdout ----
    error: could not exec the linker `gcc`: OS Error 206: The filename or extension is too long.

    error: aborting due to previous error
    task 'path::GenericPath::set_extension_0' failed at 'Box<Any>', C:\bot\slave\auto-win32-32-opt\b\src\libsyntax\ast_util.rs:784

Windows hates long paths.

[brson]

Doesn't reproduce locally so must be related to the length of the temp dir on the bots specifically.

[brson]

The error seems related to this one on so. At some point in execution CreateProcess just starts failing with error 206 and then keeps failing. It doesn't have anything to do with the length of the tmp path.

[brson]

Related Eclipse bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=327193

[alexcrichton]

I suspect that you may want to fix this block of code to only append something once. Perhaps that's where the huge environment is coming from?

[brson]

With either RUST_TEST_TASKS=1 make check-stage2-doc-crate-core or RUST_TEST_TASKS=1 make check-stage2-doc-crate-std I get 134 passes, then all subsequent tests fail.

[alexcrichton]

In rustdoc all instances of rustc happen in the same process, so that environment variable is just continuously growing.

[brson]

@alexcrichton That is an interesting block of code! With rustdoc running in-process rustc's in parallel this is very racy (though even without parallel tests this is failing).

[brson]

It does seem like a possibility that the environment is accumulating w/o bound

[brson]

@alexcrichton That block of code does try to reset the environment, which seems like it should work sequentially.

[alexcrichton]

It is a bit racy, yes, but I'd be more worried about every test adding the same paths to PATH and it just keeps growing and growing (and the bug report just said that big processes caused problems)

[brson]

There's more racy environment code in phase 6.

[brson]

@alexcrichton This code does try to restore the original PATH. Are you seeing somewhere it doesn't?

[brson]

I'll instrument the compiler to check out the environment at every step.

[vadimcn]

Oh, is rustdoc actually running multiple compilations in parallel in the same process? Yes, in that case mutating a global variable is not good.

[brson]

The PATH variable is definitely going off the rails here even with sequential testing.

[brson]

Hm, wait. The revision I'm testing on the bots contains neither of those setenv calls.... /me confused

[brson]

It would definitely help if I was using a build of Rust that wasn't from August.

[brson]

Still investigating how master treats PATH across multiple compilations, but I can't reproduce the original error. This may be nothing (though the race is still an issue).

[brson]

Indeed I think this is not an issue.