[SR-14303] Assertion failed in TypeSystemSwiftTypeRef.cpp when running 'thread list'/'fr v' crashing lldb on Linux

[hassila]

Previous ID	SR-14303
Radar	rdar://problem/75097856
Original Reporter	@hassila
Type	Bug

Environment

Swift version 5.4-dev (LLVM d28e4b9, Swift d378e707988c0ef)
swiftdev 5.8.0-44-generic #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Additional Detail from JIRA

Votes	0
Component/s	LLDB for Swift
Labels	Bug, LLDBCrash
Assignee	None
Priority	Medium

md5: 33062a67efb520336b9d03d23335af6d

relates to:

• SR-14335 Assertion `equivalent && "TypeSystemSwiftTypeRef diverges from SwiftASTContext"' failed
• SR-14336 equivalent && "TypeSystemSwiftTypeRef diverges from SwiftASTContext part 2

Issue Description:

I tried to reproduce this but was unable manually, but ": lldb -replay /tmp/reproducer-e6ba30" did reproduce it and it crashed again.

I've put up the reproducer as a tar.gz at:https://www.icloud.com/iclouddrive/0g3sE3slMVet4lypF7-xHbuGg#reproducer-e6ba30
it is 37.5MB and can't be attached.

This is with:
(lldb) version
lldb version 10.0.0
Swift version 5.4-dev (LLVM d28e4b9, Swift d378e707988c0ef)

Trying to run 'thread list' gave me the following broken assertion:

(lldb) frame info
frame #0: 0x00005555556a505e NIOPerformanceTester`UInt32.init(value=(b12 = 0, b3 = 0)) at IntegerTypes.swift:52:38
(lldb) fr v
(NIO._UInt24) value = (b12 = 0, b3 = 0)
(UInt32) self = 0
(UInt32) newValue = 0
(lldb) fr v -a
(UInt32) self = 0
(UInt32) newValue = 0
(lldb) thread list
1 != 0
failing type was $sSuxs5Error_pIgyrzo_D
lldb: /home/build-user/llvm-project/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp:1874: virtual bool lldb_private::TypeSystemSwiftTypeRef::IsPossibleDynamicType(lldb::opaque_compiler_type_t, lldb_private::CompilerType *, bool, bool): Assertion `equivalent && "TypeSystemSwiftTypeRef diverges from SwiftASTContext"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/
and include the crash backtrace.
Stack dump:
0. Program arguments: lldb .build/x86_64-unknown-linux-gnu/debug/NIOPerformanceTester
lldb[0x421024]
lldb[0x41f0ce]
lldb[0x4214b5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f1d83afd3c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f1d79f3f18b]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f1d79f1e859]
/lib/x86_64-linux-gnu/libc.so.6(+0x25729)[0x7f1d79f1e729]
/lib/x86_64-linux-gnu/libc.so.6(+0x36f36)[0x7f1d79f2ff36]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0x140f365)[0x7f1d7b888365]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0x10aa14f)[0x7f1d7b52314f]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xfeee53)[0x7f1d7b467e53]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xedced2)[0x7f1d7b355ed2]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xedcf65)[0x7f1d7b355f65]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xee0420)[0x7f1d7b359420]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0x122e0d2)[0x7f1d7b6a70d2]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xe9ae7c)[0x7f1d7b313e7c]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xe9a6aa)[0x7f1d7b3136aa]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xe9a6aa)[0x7f1d7b3136aa]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xe9a2d1)[0x7f1d7b3132d1]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0x104ffdf)[0x7f1d7b4c8fdf]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0x10508b5)[0x7f1d7b4c98b5]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xfec45e)[0x7f1d7b46545e]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0x15b720d)[0x7f1d7ba3020d]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xf61457)[0x7f1d7b3da457]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xf5748c)[0x7f1d7b3d048c]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xf5adcc)[0x7f1d7b3d3dcc]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xea2456)[0x7f1d7b31b456]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xe86834)[0x7f1d7b2ff834]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(+0xf5c50d)[0x7f1d7b3d550d]
/home/jocke/swift/swift-5.4-DEVELOPMENT-SNAPSHOT-2021-02-21-a-ubuntu20.04/usr/bin/../lib/liblldb.so.10(_ZN4lldb10SBDebugger21RunCommandInterpreterEbb+0xf7)[0x7f1d7afc2e47]
lldb[0x40a94f]
lldb[0x40c7af]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f1d79f200b3]
lldb[0x40716e]
********************
Crash reproducer for lldb version 10.0.0
Swift version 5.4-dev (LLVM d28e4b9, Swift d378e707988c0ef)

Reproducer written to '/tmp/reproducer-e6ba30'

Before attaching the reproducer to a bug report:

• Look at the directory to ensure you're willing to share its content.

• Make sure the reproducer works by replaying the reproducer.

Replay the reproducer with the following command:
lldb -replay /tmp/reproducer-e6ba30
********************
fish: Job 1, 'lldb .build/x86_64-unknown-linu?' terminated by signal SIGABRT (Abort)
jocke@swiftdev ~/s/swift-nio (jh-liburing-fullmerge) [SIGABRT]>
jocke@swiftdev ~/s/swift-nio (jh-liburing-fullmerge) [SIGABRT]> swift --version
Swift version 5.4-dev (LLVM d28e4b9, Swift d378e707988c0ef)
Target: x86_64-unknown-linux-gnu
jocke@swiftdev ~/s/swift-nio (jh-liburing-fullmerge)> uname -a
Linux swiftdev 5.8.0-44-generic #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[typesanitizer]

@swift-ci create

[hassila]

I reproduced the same assertion failure with a simple breakpoint and a "fr v" on an optimised build. This seems reproducible for me. I did clean the whole .build directory and did a clean build due to warnings.

Aware debugging optimised builds may not be optimal experience, but runtime for the performance test I want to debug is just prohibitive otherwise and we shouldn't have a crash of the debugger anyway.

---

Process 29603 stopped

• thread [lldb][NFC] Actually test which method we call in TestCallOverriddenMethod #2, name = 'NIO-ELT-0-#0', stop reason = breakpoint 1.1

  frame #0: 0x000055555561586d NIOPerformanceTester`Uring.io_uring_peek_batch_cqe(events=0 values, self=0x00007ffff0001700) at Linux.swift:250:75 [opt]

247 currentCqeCount = CNIOLinux_io_uring_peek_batch_cqe(&ring, cqes, UInt32(cqeCount));

248 for i in 0 ..< currentCqeCount

249 {

-> 250 let bitPattern : UInt = UInt(bitPattern:io_uring_cqe_get_data(cqes[Intℹ]))

251 let fd = Int(bitPattern & 0x00000000FFFFFFFF)

252 let poll_mask = Int(bitPattern >> 32) // shift out the fd

253 print("io_uring_peek_batch_cqe bitPattern[" + String(bitPattern).decimalToHexa + "] bit[(bitPattern)] fd[(fd)] i[(i)] poll_mask[(poll_mask)] currentCqeCount[(currentCqeCount)] cqes[Intℹ][(String(describing:cqes[Intℹ]))]")

Target 0: (NIOPerformanceTester) stopped.

(lldb) fr v

TypeSystemSwiftTypeRef diverges from SwiftASTContext: $sSPys6UInt32VGD != $sSpys6UInt32VGXSqD

failing type was $sSo11io_uring_sqVD

lldb: /home/build-user/llvm-project/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp:2539: virtual lldb_private::CompilerType lldb_private::TypeSystemSwiftTypeRef::GetChildCompilerTypeAtIndex(lldb::opaque_compiler_type_t, lldb_private::ExecutionContext *, size_t, bool, bool, bool, std::string &, uint32_t &, int32_t &, uint32_t &, uint32_t &, bool &, bool &, lldb_private::ValueObject *, uint64_t &): Assertion `equivalent && "TypeSystemSwiftTypeRef diverges from SwiftASTContext"' failed.

PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.

Stack dump:

0. Program arguments: lldb .build/x86_64-unknown-linux-gnu/release/NIOPerformanceTester

---

Additional reproducer can be downloaded here:

https://www.icloud.com/iclouddrive/0wvtUumwlNxYZspqjhBcM0SCg#reproducer-88db7f

[hassila]

Added a third link for another similar reproducer:

---

TypeSystemSwiftTypeRef diverges from SwiftASTContext:

l = 75497473 | eTypeHasChildren | eTypeIsSwift | eTypeIsTuple

r = 8390658 | eTypeHasValue | eTypeIsPointer | eTypeIsSwift

failing type was $syyXED

lldb: /home/build-user/llvm-project/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp:1969: virtual uint32_t lldb_private::TypeSystemSwiftTypeRef::GetTypeInfo(lldb::opaque_compiler_type_t, lldb_private::CompilerType *): Assertion `equivalent && "TypeSystemSwiftTypeRef diverges from SwiftASTContext"' failed.

---

[weissi]

CC @dcci/jingham@apple.com (JIRA User)/@adrian-prantl

[adrian-prantl]

Joakim, I appreciate all the reports, but it would be best to file separate bugs. All three assertion failures posted here are distinct and have nothing to do with each other. (The first is a flag, the second is validating two types, and the third one is a bitfield). We don't get that many bug reports for LLDB on Linux, and it's cheap to mark two reports as duplicates, but if you pile on to another bug it's quite easy for us to loose track your issue because it's buried deep in the comments.

Note that these assertions are mostly QoI issues and there's a good chance that a non-asserts LLDB will work fine, but they of course still need to investigated!

[hassila]

Thanks Adrian, I have split out case 2 and 3 to SR-14335 and SR-14336 respectively. I will field separate Jira issues going forward if they aren't exact duplicates.

[adrian-prantl]

Thanks, and thanks for reporting the issue in the first place! This will make it much easier to keep track.