intermittent linker errors on 32-bit MSVC builds

[dimbleby]

32-bit MSVC builds for my c-ares-resolver project intermittently fail like this:

fatal error LNK1318: Unexpected PDB error; RPC (23) '(0x000006BA)'

Appveyor build history showing lots of failures here.

This looks similar to #3161, but fixes made there are surely long released - so I suppose this is something else.

(It wasn't clear to me whether I should be raising this against cargo or rustc or what - apologies if I've guessed wrong).

[alexcrichton]

I wonder if this may have to do with racing build scripts? Unfortunately I don't know how this could resurface :(

The problem here is that a link.exe is killed when multiple processes are using it, and the other processes all fail with an error when that happens. Do you have anything in your build which executes cargo or rustc?

[dimbleby]

The failing step is cargo test. I'm not doing anything else that runs cargo or rustc, though.

[dimbleby]

That will involve building the three separate programs that I have in examples. Does cargo do this in parallel? Perhaps something going wrong there?

This would be consistent with the fact that the corresponding build for the rust-c-ares project does not fail in this way - in that one I (weirdly) structured my examples as one big program.

[dimbleby]

FWIW I've had two examples since forever, but first saw this failure on 4th August in this build with rustc 1.19.0 and cargo 0.20.0.

If the issue was provoked by something I changed: well, here is the change - tweaking the way that rust is installed on the appveyor boxes.

Builds before that look to have been consistently successful (at least from the point of view of this problem).

[alexcrichton]

Ah sorry what I meant is that as part of the build, for example in a build script, are you running rustc/cargo/rustup/etc?

[dimbleby]

Not sure whether you missed my answer - which would be my own fault for then making two additional updates - or I misunderstood the question.

The failing step is cargo test. I'm not doing anything else that runs cargo or rustc, though.

Does that answer the question?

[alexcrichton]

Yes I understand you're executing cargo test. I'm wondering if within that cargo test the build is executing something like rustc --version or compiling a shim in a build script.

[dimbleby]

No, there's no build script.

(there is a build script in a dependency - c-ares-sys - but I have just experimented with separating cargo build and cargo test, and still see failures at cargo test, so I don't think that can be relevant.

I'm currently experimenting with cargo test -j1 and provisionally this looks as though it might be a successful workaround, though I'll want a few more clean builds before I'm convinced).

Edit: I'm now persuaded that cargo test -j1 is a successful workaround.

[alexcrichton]

Looking at some failing logs it looks like the failure is isolated to i686 and always happens on the c-ares crate itself (typically in examples, sometimes not). Basically this looks precisely like rust-lang/rust#33145, so something is killing a linker (presumably).

Can you try setting RUST_LOG=rustup-cli=info,cargo::util::job and see what's printed?

[dimbleby]

build under way.

[alexcrichton]

Hm maybe rustup_cli instead of rustup-cli?

[alexcrichton]

(I forget the precise syntax)

[dimbleby]

well I've never known about this, much less forgotten it! Happy to follow instructions - just let me know what you want to try.

(having said that I'll be away from the computer soon so will shortly go unresponsive)

meanwhile I see that the previous build exhibited no failures - obviously when you want it to fail it doesn't! - I'll kick off another. EDIT: and now we have a failure, though it doesn't look to me as though the additional logging says very much. Hopefully that lack of output is useful...

[Geobert]

Even in 64bits build we got this error in cobalt.rs project: cobalt-org/cobalt.rs#352

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[stale]

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!