Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-14556] Release version of Swift/LLDB is built with asserts #4314

Closed
hassila opened this issue Apr 30, 2021 · 12 comments
Closed

[SR-14556] Release version of Swift/LLDB is built with asserts #4314

hassila opened this issue Apr 30, 2021 · 12 comments
Assignees
@augusto2112
Labels
bug Something isn't working LLDB for Swift

Comments

@hassila
Copy link

hassila commented Apr 30, 2021

Previous ID SR-14556
Radar rdar://problem/77383305
Original Reporter @hassila
Type Bug
Status Closed
Resolution Done
Environment 
lldb version 10.0.0
Swift version 5.4 (swift-5.4-RELEASE)
ubuntu@ip-172-31-25-161 ~/s/swift-nio (jh-new-liburing)> uname -a
Linux ip-172-31-25-161 5.12.0-rc7-5.13-uring-210421 #​1 SMP Wed Apr 21 07:56:24 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Additional Detail from JIRA
Votes 2
Component/s LLDB for Swift
Labels Bug
Assignee @augusto2112
Priority Medium

md5: e2ec1ebdcffcd4242cb78f6fb98d0312

Issue Description:

Basically, the shipped release versions of LLDB are unusable on Linux as asserts are built in that are triggered for basically most p/po operations. Simple example attached.

Would be great if the release versions could be built without asserts, as it is quite painful for new Linux server developers to try to use Swift/LLDB as it basically can't be used in the current state. If rolling ones own without asserts, it works ok though - so this case is just to ask to please change the build infrastructure for releases to not have asserts - please and thank you! :-)

Target 0: (NIOPerformanceTester) stopped.
(lldb) bt
* thread #​1, name = 'NIOPerformanceT', stop reason = signal SIGSTOP
  * frame #&#8203;0: 0x00005555555b4a70 NIOPerformanceTester`ByteBuffer._ensureAvailableCapacity(capacity=<unavailable>, index=<unavailable>, self=<unavailable>) at ByteBuffer-core.swift:339:5 [opt]
    frame #&#8203;1: 0x00005555555b4af1 NIOPerformanceTester`ByteBuffer._setBytes(bytes=4 values (0x7fffffffe3e8), index=(_value = 6445448), self=NIO.ByteBuffer @ 0x00007fffffffe430) at ByteBuffer-core.swift:375:14 [opt]
    frame #&#8203;2: 0x00005555555b0b1c NIOPerformanceTester`ByteBuffer.setString(_:at:) [inlined] closure #&#8203;1 (utf8Bytes=<unavailable>, self=<unavailable>, index=<unavailable>, utf8Bytes=<unavailable>, self=NIO.ByteBuffer @ 0x00007fffffffe430, index=6445448) -> Swift.Int in NIO.ByteBuffer.setString(_: Swift.String, at: Swift.Int) -> Swift.Int at ByteBuffer-aux.swift:0 [opt]
    frame #&#8203;3: 0x00005555555b0b11 NIOPerformanceTester`ByteBuffer.setString(_:at:) [inlined] reabstraction thunk helper from @callee_guaranteed (@unowned Swift.UnsafeBufferPointer<Swift.UInt8>) -> (@unowned Swift.Int, @error @owned Swift.Error) to @escaping @callee_guaranteed (@unowned Swift.UnsafeBufferPointer<Swift.UInt8>) -> (@out Swift.Int, @error @owned Swift.Error) at <compiler-generated>:0 [opt]
    frame #&#8203;4: 0x00005555555b0b11 NIOPerformanceTester`ByteBuffer.setString(_:at:) [inlined] generic specialization <serialized, Swift.Int> of Swift.String.UTF8View.withContiguousStorageIfAvailable<τ_0_0>((Swift.UnsafeBufferPointer<Swift.UInt8>) throws -> τ_0_0) throws -> Swift.Optional<τ_0_0> at <compiler-generated>:0 [opt]
    frame #&#8203;5: 0x00005555555b0b11 NIOPerformanceTester`ByteBuffer.setString(string="\0\0\0\0", index=6445448, self=NIO.ByteBuffer @ 0x00007fffffffe430) at ByteBuffer-aux.swift:118 [opt]
    frame #&#8203;6: 0x00005555555b0a5a NIOPerformanceTester`ByteBuffer.writeString(string=<unavailable>, self=NIO.ByteBuffer @ 0x00007fffffffe430) at ByteBuffer-aux.swift:88:28 [opt]
    frame #&#8203;7: 0x000055555568571d NIOPerformanceTester`closure #&#8203;4 in  at main.swift:212:20 [opt]
    frame #&#8203;8: 0x000055555568318b NIOPerformanceTester`measure(_:) at main.swift:34:17 [opt]
    frame #&#8203;9: 0x0000555555683170 NIOPerformanceTester`measure(fn=0x0000555555685670 NIOPerformanceTester`closure #&#8203;4 () -> Swift.Int in NIOPerformanceTester at main.swift:205) at main.swift:42 [opt]
    frame #&#8203;10: 0x000055555568348d NIOPerformanceTester`measureAndPrint(desc=<unavailable>, fn=0x0000555555685670 NIOPerformanceTester`closure #&#8203;4 () -> Swift.Int in NIOPerformanceTester at main.swift:205) at main.swift:53:32 [opt]
    frame #&#8203;11: 0x00005555556813df NIOPerformanceTester`main at main.swift:205:1 [opt]
    frame #&#8203;12: 0x00007ffff6e6f0b3 libc.so.6`__libc_start_main + 243
    frame #&#8203;13: 0x0000555555592abe NIOPerformanceTester`_start + 46
(lldb) f 4
frame #&#8203;4: 0x00005555555b0b11 NIOPerformanceTester`ByteBuffer.setString(_:at:) [inlined] generic specialization <serialized, Swift.Int> of Swift.String.UTF8View.withContiguousStorageIfAvailable<τ_0_0>((Swift.UnsafeBufferPointer<Swift.UInt8>) throws -> τ_0_0) throws -> Swift.Optional<τ_0_0> at <compiler-generated>:0 [opt]
(lldb) list
(lldb) f 7
frame #&#8203;7: 0x000055555568571d NIOPerformanceTester`closure #&#8203;4 in  at main.swift:212:20 [opt]
   209      for _ in 0 ..< 5 {
   210          buffer.clear()
   211          for _ in 0 ..< (bufferSize / 4) {
-> 212              buffer.writeString("abcd")
   213          }
   214      }
   215  
(lldb) p buffer
lldb: /home/build-user/swift/include/swift/AST/Type.h:220: swift::TypeBase *swift::Type::operator->() const: Assertion `Ptr && "Cannot dereference a null Type!"' failed.
fish: Job 1, 'lldb .build/x86_64-unknown-linu?' terminated by signal SIGABRT (Abort)
ubuntu@ip-172-31-25-161 ~/s/swift-nio (jh-new-liburing) [SIGABRT]> lldb --version
lldb version 10.0.0
Swift version 5.4 (swift-5.4-RELEASE)
@hassila
Copy link
Author

hassila commented Apr 30, 2021

The packaged used was https://swift.org/builds/swift-5.4-release/ubuntu2004/swift-5.4-RELEASE/swift-5.4-RELEASE-ubuntu20.04.tar.gz from swift.org.

@adrian-prantl
Copy link
Member

@swift-ci create

1 similar comment
@adrian-prantl
Copy link
Member

@swift-ci create

@adrian-prantl
Copy link
Member

As a side note, for completeness, this particular assertion looks like it would just result in a crash if removed.

@hassila
Copy link
Author

hassila commented Apr 30, 2021

Ouch :-/

Thanks for clarification. Unfortunately it didn't give me a reproducer, but basically it seems easy to break lldb by simply stopping arbitrary Swift programs and try to inspect structs/objects/... in this case it was the NIOPerformanceTester from SwiftNIO I used. (basically I wanted to validate if I could move from my 5.3.3 custom built toolchain without asserts to the official 5.4 release, as I'd prefer not to have to roll my own...)

@hassila
Copy link
Author

hassila commented Apr 30, 2021

Ok, played a bit more and now got a reproducer with the same assert AFAICT.

Here you go:
https://www.icloud.com/iclouddrive/0uI1CN25RxFGiGfN3SaqAJKOw#reproducer-d2a1e9

@hassila
Copy link
Author

hassila commented Apr 30, 2021

Short version:

(lldb) f 4
frame #&#8203;4: 0x0000555555683170 NIOPerformanceTester`measure(fn=0x0000555555685670 NIOPerformanceTester`closure #&#8203;4 () -> Swift.Int in NIOPerformanceTester at main.swift:205) at main.swift:42 [opt]
   39       _ = try measureOne(fn) /* pre-heat and throw away */
   40       var measurements = Array(repeating: 0.0, count: 10)
   41       for i in 0..<10 {
-> 42           measurements[i] = try measureOne(fn)
   43       }
   44   
   45       return measurements
(lldb) p measurements
lldb: /home/build-user/swift/include/swift/AST/Type.h:220: swift::TypeBase *swift::Type::operator->() const: Assertion `Ptr && "Cannot dereference a null Type!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.

@adrian-prantl
Copy link
Member

Thanks Joakim! Do you happen to have instructions for how to build NIOPerformanceTester? Unfortunately LLDB reproducers involving Swift are not quite as reliable yet.

@hassila
Copy link
Author

hassila commented Apr 30, 2021

Sure!

Just clone https://github.com/apple/swift-nio and build with e.g.:

swift run -c release NIOPerformanceTester

break with ctrl-c or let it run through, then run it in lldb:

 lldb .build/x86_64-unknown-linux-gnu/release/NIOPerformanceTester

after it has run for a few seconds, just ctrl-c to break into debugger, use "f xxx" to pick a frame with symbols and try to use "p" on some relevant object in the frame.

Repeat a few times and move to a different frame if needed, for me it usually crashes on the first try.

@weissi
Copy link
Member

weissi commented May 1, 2021

@hassila FYI, I created lldb-smoker which is an LLDB smoke test for SwiftNIO (or any other Swift package with good test coverage): https://github.com/apple/swift-nio/pull/1840/files

It just creates 2000 totally random breakpoints, and when hit runs frame variable , then continues. No user interaction required. On 5.4 it hits crashes.

Instructions how to use:

# Step 1: Get yourself a NIO checkout with `lldb-smoker` from my PR
#         it'll create /tmp/swift-nio
cd /tmp && rm -rf swift-nio && git clone https://github.com/apple/swift-nio.git && cd swift-nio && git fetch origin pull/1840/head && git checkout -b lldb-smoker FETCH_HEAD

# Step 2: Run lldb-smoker on your host platform
dev/lldb-smoker # yes, this is all you need. If you want to run it on another Swift package, just pass the path the package as an argument

# Step 3 (run in docker, optional): Run lldb-smoker on Linux, this can be run for your Mac, the only thing  you need installed is Docker for Mac
#         (Docker for Mac is just a click-through installer, no config required)
docker run -it --rm -v "$PWD:$PWD" -w "$PWD" --privileged swift:5.4 dev/lldb-smoker

@hassila
Copy link
Author

hassila commented May 3, 2021

Thanks @weissi - I just tried that on Linux - crashed both times I tried it within a few seconds in different places - very nice smoker, would be awesome if it was part of the qualification of lldb in the future!

Samples from 5.4-release on Ubuntu 20.04:

First run:
....
0 != 1
failing type was $s3NIO12NIOBSDSocketO6HandleaD
lldb: /home/build-user/llvm-project/lldb/source/Plugins/TypeSystem/Swift/TypeSystemSwiftTypeRef.cpp:1715: virtual bool lldb_private::TypeSystemSwiftTypeRef::IsAggregateType(lldb::opaque_compiler_type_t): Assertion `equivalent && "TypeSystemSwiftTypeRef diverges from SwiftASTContext"' failed.
dev/lldb-smoker: line 67:  9822 Aborted                 (core dumped) 

Second run:
.....
"${lldb_command[@]}"...
failing type was $sSo19pthread_mutexattr_taD
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.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.

@augusto2112
Copy link

PR: #3048

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@augusto2112 augusto2112

Labels
bug Something isn't working LLDB for Swift
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@weissi @adrian-prantl @augusto2112 @hassila