Exception Code: 0xC000001D after Associative COMDAT symbol

[ColinHexagon]

Hello,

While building a C++ project with clang (Release options, -fprofile-instr-generate -fcoverage-mapping -emit-llvm) on Windows,
lld-link.exe crashed? and asked me to create a bug report here.

This following error is printed:

LLVM ERROR: Associative COMDAT symbol '??0type_error@pybind11@@QEAA@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z' does not exist.

Followed by:

1.      Running pass 'Function Pass Manager' on module 'ld-temp.o'.
2.      Running pass 'X86 Assembly Printer' on function '@"??0type_error@pybind11@@QEAA@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z.6331"'
Exception Code: 0xC000001D

Followed by the stacktrace:
 #0 0x00007ff79c94d346 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xcd346)
 #1 0x00007ffc29271881 (C:\WINDOWS\System32\ucrtbase.dll+0x71881)
 #2 0x00007ffc29272851 (C:\WINDOWS\System32\ucrtbase.dll+0x72851)
 #3 0x00007ff79c9584a3 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xd84a3)
 #4 0x00007ff79d16cd86 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x8ecd86)
 #5 0x00007ff79d16cfbb (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x8ecfbb)
 #6 0x00007ff79d1944f2 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x9144f2)
 #7 0x00007ff79dae49c0 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x12649c0)
 #8 0x00007ff79dae6b3f (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x1266b3f)
 #9 0x00007ff79cc87039 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x407039)
#10 0x00007ff79d50da5d (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xc8da5d)
#11 0x00007ff79d28dc1a (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xa0dc1a)
#12 0x00007ff79d293903 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xa13903)
#13 0x00007ff79d28e293 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xa0e293)
#14 0x00007ff79d037533 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x7b7533)
#15 0x00007ff79d0362f0 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x7b62f0)
#16 0x00007ff79cb29810 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x2a9810)
#17 0x00007ff79cb28f6c (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x2a8f6c)
#18 0x00007ff79ce7c17e (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x5fc17e)
#19 0x00007ff79cb1b743 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x29b743)
#20 0x00007ff79c8c453f (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x4453f)
#21 0x00007ff79c8bd11c (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x3d11c)
#22 0x00007ff79c881cd0 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x1cd0)
#23 0x00007ff79c881444 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x1444)
#24 0x00007ff79f59b1b4 xmlLinkGetData (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x2d1b1b4)
#25 0x00007ffc2b967344 (C:\WINDOWS\System32\KERNEL32.DLL+0x17344)
#26 0x00007ffc2baa26b1 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x526b1)

lld-link --version returns:
LLD 16.0.6

clang --version returns:
clang version 16.0.6
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

[llvmbot]

@llvm/issue-subscribers-lld-coff

Author: None (ColinHexagon)

Hello,

While building a C++ project with clang (Release options, -fprofile-instr-generate -fcoverage-mapping -emit-llvm) on Windows,
lld-link.exe crashed? and asked me to create a bug report here.

This following error is printed:

LLVM ERROR: Associative COMDAT symbol '??0type_error@<!-- -->pybind11@@<!-- -->QEAA@<!-- -->AEBV?$basic_string@<!-- -->DU?$char_traits@<!-- -->D@<!-- -->std@@<!-- -->V?$allocator@<!-- -->D@<!-- -->2@@<!-- -->std@@@<!-- -->Z' does not exist.

Followed by:

1.      Running pass 'Function Pass Manager' on module 'ld-temp.o'.
2.      Running pass 'X86 Assembly Printer' on function '@"??0type_error@<!-- -->pybind11@@<!-- -->QEAA@<!-- -->AEBV?$basic_string@<!-- -->DU?$char_traits@<!-- -->D@<!-- -->std@@<!-- -->V?$allocator@<!-- -->D@<!-- -->2@@<!-- -->std@@@<!-- -->Z.6331"'
Exception Code: 0xC000001D

Followed by the stacktrace:
 #<!-- -->0 0x00007ff79c94d346 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xcd346)
 #<!-- -->1 0x00007ffc29271881 (C:\WINDOWS\System32\ucrtbase.dll+0x71881)
 #<!-- -->2 0x00007ffc29272851 (C:\WINDOWS\System32\ucrtbase.dll+0x72851)
 #<!-- -->3 0x00007ff79c9584a3 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xd84a3)
 #<!-- -->4 0x00007ff79d16cd86 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x8ecd86)
 #<!-- -->5 0x00007ff79d16cfbb (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x8ecfbb)
 #<!-- -->6 0x00007ff79d1944f2 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x9144f2)
 #<!-- -->7 0x00007ff79dae49c0 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x12649c0)
 #<!-- -->8 0x00007ff79dae6b3f (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x1266b3f)
 #<!-- -->9 0x00007ff79cc87039 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x407039)
#<!-- -->10 0x00007ff79d50da5d (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xc8da5d)
#<!-- -->11 0x00007ff79d28dc1a (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xa0dc1a)
#<!-- -->12 0x00007ff79d293903 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xa13903)
#<!-- -->13 0x00007ff79d28e293 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0xa0e293)
#<!-- -->14 0x00007ff79d037533 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x7b7533)
#<!-- -->15 0x00007ff79d0362f0 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x7b62f0)
#<!-- -->16 0x00007ff79cb29810 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x2a9810)
#<!-- -->17 0x00007ff79cb28f6c (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x2a8f6c)
#<!-- -->18 0x00007ff79ce7c17e (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x5fc17e)
#<!-- -->19 0x00007ff79cb1b743 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x29b743)
#<!-- -->20 0x00007ff79c8c453f (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x4453f)
#<!-- -->21 0x00007ff79c8bd11c (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x3d11c)
#<!-- -->22 0x00007ff79c881cd0 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x1cd0)
#<!-- -->23 0x00007ff79c881444 (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x1444)
#<!-- -->24 0x00007ff79f59b1b4 xmlLinkGetData (C:\PROGRA~1\LLVM\bin\lld-link.exe+0x2d1b1b4)
#<!-- -->25 0x00007ffc2b967344 (C:\WINDOWS\System32\KERNEL32.DLL+0x17344)
#<!-- -->26 0x00007ffc2baa26b1 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x526b1)

lld-link --version returns:
LLD 16.0.6

clang --version returns:
clang version 16.0.6
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

[aganea]

Are you able to test the link step with the latest LLD, see if the bug is still present?

[mstorsjo]

Are you able to make a link reproducer? Add -reproduce:repro.tar to the lld-link command, and it will bundle up all relevant input files into a file, which can be shared with us, allowing anybody to reproduce the same error.

[mizvekov]

@mstorsjo I have run into this problem as well.

Reproducer attached.
repro.zip

[mstorsjo]

@mstorsjo I have run into this problem as well.

Thanks, I'm able to reproduce this error using this package.

[mstorsjo]

@mstorsjo I have run into this problem as well.

Reproducer attached. repro.zip

While it's possible to reproduce the issue with this, it's a bit hard to get an overview of what's really happening...

Are you able to reduce the reproducer on a source level, so that you'd be able to share a minimal (or at least small) source level reproducer for the issue?

---

I had a quick look at this, and something goes wrong in some of the LTO optimization passes. If looking at the input file root/psinex/build/aarch64-win-rel/ext/catch2/CMakeFiles/ext.catch2.obj.dir/catch2/internal/catch_test_case_tracker.cpp.obj, running llvm-dis on it, I get IR that contains this:

$"??_7SectionTracker@TestCaseTracking@Catch@@6B@" = comdat any
[...]
@"??_7SectionTracker@TestCaseTracking@Catch@@6B@" = linkonce_odr unnamed_addr constant { [6 x ptr] } { [6 x ptr] [ptr @"??_GSectionTracker@TestCaseTracking@Catch@@UEAAPEAXI@Z", ptr @"?isComplete@SectionTracker@TestCaseTracking@Catch@@UEBA_NXZ", ptr @"?close@TrackerBase@TestCaseTracking@Catch@@UEAAXXZ", ptr @"?fail@TrackerBase@TestCaseTracking@Catch@@UEAAXXZ", ptr @"?isSectionTracker@SectionTracker@TestCaseTracking@Catch@@UEBA_NXZ", ptr @"?isGeneratorTracker@ITracker@TestCaseTracking@Catch@@UEBA_NXZ"] }, comdat, !type !0, !type !15, !type !31, !vcall_visibility !1

I.e. we have a declaration and a definition of this comdat object.

If I run the LTO compilation with lld-link @response.txt -lldemit:llvm -out:out.bc, then convert the LTO output with llvm-dis out.bc back into textual IR, I see this:

$"??_7SectionTracker@TestCaseTracking@Catch@@6B@" = comdat any

I only see a declaration of the comdat, but no definition. There's one reference to it elsewhere in the LTO output:

@"__typeid_?AVITracker@TestCaseTracking@Catch@@_32_unique_member" = hidden unnamed_addr constant { [6 x ptr] } { [6 x ptr] [ptr @"??_GSectionTracker@TestCaseTracking@Catch@@UEAAPEAXI@Z.llvm.merged", ptr @"?isComplete@SectionTracker@TestCaseTracking@Catch@@UEBA_NXZ.llvm.merged", ptr @"?close@TrackerBase@TestCaseTracking@Catch@@UEAAXXZ", ptr @"?fail@TrackerBase@TestCaseTracking@Catch@@UEAAXXZ", ptr @"?isSectionTracker@SectionTracker@TestCaseTracking@Catch@@UEBA_NXZ", ptr @"?isGeneratorTracker@ITracker@TestCaseTracking@Catch@@UEBA_NXZ"] }, comdat($"??_7SectionTracker@TestCaseTracking@Catch@@6B@"), !type !54728, !type !54729, !type !55527

So, during the LTO optimization phases, something optimizes out the definition of this comdat, even if it evidently still is needed somewhere.