1517685 - lld-link.exe: error: codeview::mergeTypeAndIdRecords failed: CodeView Error: The CodeView record is corrupted. input type graph contains cycles

Status: RESOLVED INCOMPLETE

(Firefox Build System :: Toolchains, defect)

Description

[Cameron McCormack (:heycam)]

I got the above error on a try push:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=40798e23afe1f0abdce82f7b6dcb9e67a3399b5a

Comment 1

[(not currently active) Ted Mielczarek]

Interesting. Your changes are mostly Rust? I guess something there could be causing rustc to emit debug info that lld-link doesn't like?

Comment 2

[(not currently active) Ted Mielczarek]

There was also a clang update that landed and got backed out for build time regressions (bug 1512921), so it'd be worth trying your changes on top of those patches as well to see if this is something that got fixed in upstream llvm.

Comment 3

[Cameron McCormack (:heycam)]

Unfortunately that patch didn't help: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6adc6b245727d580a630ec92e6b82ab7c94d3921&group_state=expanded&selectedJob=220246045

It's purely Rust changes.  Part of it is adding mozilla::detail::GkAtoms to the list of things rust-bindgen generates, and that type is big -- it has 2,400 member variables, and is 83,540 bytes (on x64).  I wonder if that could be related.

Comment 4

[Cameron McCormack (:heycam)]

Removing GkAtoms from the list of rust-bindgen generated types avoids the problem:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=59890432f7fe3b5c619438aa6b5056ac34c2129c

Comment 5

[(not currently active) Ted Mielczarek]

Interesting! Do you have a Windows build environment where you can reproduce this locally? It sounds like it'd be worth roping in mw or someone else that deals with rustc internals on this.

Comment 6

[Michael Woerister]

cc'ing Tom too...

Comment 7

[Nathan Froyd [:froydnj]]

MSVC has a limit on character constants of 65536 bytes, so perhaps GkAtoms's large size needs to be handled specially, and Rust's version of LLVM isn't doing that...?

Comment 8

[Cameron McCormack (:heycam)]

I tried building my patches locally with a recently mach bootstrapped clang, but couldn't reproduce.

(In reply to Nathan Froyd [:froydnj] from comment #7)

MSVC has a limit on character constants of 65536 bytes, so perhaps GkAtoms's
large size needs to be handled specially, and Rust's version of LLVM isn't
doing that...?

Is that the limit of the number of char[] constants, or the maximum length of a single char[] constant? (The total size of character data in GkAtoms is larger than 64 KiB but each individual atom's char[] array is short.)

Comment 9

[Cameron McCormack (:heycam)]

(In reply to Cameron McCormack (:heycam) from comment #8)

(The total size of character data in GkAtoms is larger than 64 KiB but each individual atom's char[] array is short.)

Oh, I was wrong about that -- the character data in GkAtoms is 54,764 bytes.

Comment 10

[Nathan Froyd [:froydnj]]

(In reply to Cameron McCormack (:heycam) from comment #8)

(In reply to Nathan Froyd [:froydnj] from comment #7)

MSVC has a limit on character constants of 65536 bytes, so perhaps GkAtoms's
large size needs to be handled specially, and Rust's version of LLVM isn't
doing that...?

Is that the limit of the number of char[] constants, or the maximum length of a single char[] constant? (The total size of character data in GkAtoms is larger than 64 KiB but each individual atom's char[] array is short.)

AFAIK, it's the maximum length of a single char[] constant, but I was speculating that maybe the 16-bit limit applies to other things in CodeView, and there's something else going wrong.

Comment 11

[(Away)]

(In reply to Cameron McCormack (:heycam) from comment #8)

I tried building my patches locally with a recently mach bootstrapped clang,
but couldn't reproduce.

What's your clang-cl --version? Unless you ran bootstrap in the brief period of time between when we updated the compiler and when that got backed out, you're probably running the same version as automation.(Which would mean there's some additional factor at play, beyond just compiler revision.)

Comment 12

[Cameron McCormack (:heycam)]

It's clang version 7.0.0 (tags/RELEASE_700/final 342383).

Comment 13

[Nathan Froyd [:froydnj]]

I'm going to go ahead and resolve this; heycam appears to have worked around the problem, and whatever problem it wasn't hasn't come up again. We can reopen if need be.