swiftlang / sourcekit-lsp

Language Server Protocol implementation for Swift and C-based languages
Apache License 2.0
3.3k stars 273 forks source link

Revision e1f80e4643b0 crashes due to null-pointer dereference upon starting #1469

Closed khng300 closed 3 months ago

khng300 commented 3 months ago

Swift version

Apple Swift version 6.0-dev (LLVM 579155491d559cc, Swift b07a2aa204d6487)

Platform

macOS 14.5

Editor

Visual Studio Code

Does the issue reproduce with Swift 6?

Yes

Description

thread stacktrace from LLDB:

Process 17524 stopped
* thread #2, queue = 'com.apple.root.user-initiated-qos.cooperative', stop reason = EXC_BAD_ACCESS (code=1, address=0x4)
    frame #0: 0x000000010118128c sourcekit-lsp`TaskLocal.withValue<A>(_:operation:isolation:file:line:) at <compiler-generated>:0 [opt]
Note: this address is compiler-generated code in function back deployment thunk for Swift.TaskLocal.withValue<τ_0_0>(_: τ_0_0, operation: () async throws -> τ_1_0, isolation: isolated Swift.Optional<Swift.Actor>, file: Swift.String, line: Swift.UInt) async throws -> τ_1_0 that has no source code associated with it.
Target 0: (sourcekit-lsp) stopped.
warning: sourcekit-lsp was compiled with optimization - stepping may behave oddly; variables may not be available.
(lldb) bt
Could not import Swift modules for translation unit: failed to get module "TSCBasic" from AST context:
error: could not find module 'TSCBasic' for target 'arm64-apple-macos'; found: arm64-apple-macosx10.15, at: /Library/Developer/Toolchains/swift-LOCAL-2024-06-08-a.xctoolchain/usr/lib/swift/macosx/TSCBasic.swiftmodule
* thread #2, queue = 'com.apple.root.user-initiated-qos.cooperative', stop reason = EXC_BAD_ACCESS (code=1, address=0x4)
  * frame #0: 0x000000010118128c sourcekit-lsp`TaskLocal.withValue<A>(_:operation:isolation:file:line:) at <compiler-generated>:0 [opt]
    frame #1: 0x0000000101181548 sourcekit-lsp`withLoggingScope<τ_0_0>(scope="request-0", operation=0x00000001028875e8 async function pointer to partial apply forwarder for closure #1 @Sendable () async -> () in closure #1 @Sendable () async -> () in SourceKitLSP.SourceKitLSPServer.handle<τ_0_0 where τ_0_0: LanguageServerProtocol.RequestType>(_: τ_0_0, id: LanguageServerProtocol.RequestID, reply: @Sendable (Swift.Result<τ_0_0.Response, LanguageServerProtocol.ResponseError>) -> ()) -> ()) at LoggingScope.swift:85 [opt]
    frame #2: 0x000000010187f9ec sourcekit-lsp`closure #1 in SourceKitLSPServer.handle<τ_0_0>(signposter=$s2os12OSSignposterVD @ 0x000000012860e740, signpostID=(rawValue = 1), id=<unavailable>, params=<unavailable>, reply=0x0000000101255de8 sourcekit-lsp`partial apply forwarder for generic not re-abstracted specialization <LanguageServerProtocol.InitializeRequest> of closure #1 @Sendable (Swift.Result<A.Response, LanguageServerProtocol.ResponseError>) -> () in LanguageServerProtocol.RequestType._handle(_: LanguageServerProtocol.MessageHandler, id: LanguageServerProtocol.RequestID, reply: @Sendable (Swift.Result<LanguageServerProtocol.ResponseType, LanguageServerProtocol.ResponseError>, LanguageServerProtocol.RequestID) -> ()) -> () at <compiler-generated>, state=0x000000012860e330) at SourceKitLSPServer.swift:617 [opt]
    frame #3: 0x00000001018ac8fc sourcekit-lsp`(1) await resume partial function for partial apply forwarder for closure #1 @Sendable () async -> () in SourceKitLSP.SourceKitLSPServer.handle<τ_0_0 where τ_0_0: LanguageServerProtocol.RequestType>(_: τ_0_0, id: LanguageServerProtocol.RequestID, reply: @Sendable (Swift.Result<τ_0_0.Response, LanguageServerProtocol.ResponseError>) -> ()) -> ()
    frame #4: 0x0000000101adaa5c sourcekit-lsp`thunk for @escaping @callee_guaranteed @Sendable @async () -> (@out A1) at <compiler-generated>:0 [opt]
    frame #5: 0x0000000101adc760 sourcekit-lsp`(1) await resume partial function for partial apply forwarder for reabstraction thunk helper <τ_0_0><τ_1_0 where τ_0_0: SwiftExtensions.DependencyTracker, τ_1_0: Swift.Sendable> from @escaping @callee_guaranteed @Sendable @async () -> (@out τ_1_0) to @escaping @callee_guaranteed @Sendable @async () -> (@out τ_1_0, @error @owned Swift.Error)
    frame #6: 0x0000000101adb77c sourcekit-lsp`closure #2 in closure #1 in AsyncQueue.asyncThrowing<τ_0_0>(dependencies=<could not get Swift runtime type info for type $sSay15SwiftExtensions11PendingTask33_EBE65A2403A3B911FDA5679D5408DB63LLVyxGGD>, operation=0x0000000102896700 async function pointer to partial apply forwarder for reabstraction thunk helper <τ_0_0><τ_1_0 where τ_0_0: SwiftExtensions.DependencyTracker, τ_1_0: Swift.Sendable> from @escaping @callee_guaranteed @Sendable @async () -> (@out τ_1_0) to @escaping @callee_guaranteed @Sendable @async () -> (@out τ_1_0, @error @owned Swift.Error), pendingTasks=<unavailable>, id=77B02A5A-56E0-4832-ABD6-B0DB9A91E5F9) at AsyncQueue.swift:147 [opt]
    frame #7: 0x0000000101adc5b0 sourcekit-lsp`partial apply for closure #2 in closure #1 in AsyncQueue.asyncThrowing<A>(priority:metadata:operation:) at <compiler-generated>:0 [opt]
(lldb) frame select 2
frame #2: 0x000000010187f9ec sourcekit-lsp`closure #1 in SourceKitLSPServer.handle<τ_0_0>(signposter=$s2os12OSSignposterVD @ 0x000000012860e740, signpostID=(rawValue = 1), id=<unavailable>, params=<unavailable>, reply=0x0000000101255de8 sourcekit-lsp`partial apply forwarder for generic not re-abstracted specialization <LanguageServerProtocol.InitializeRequest> of closure #1 @Sendable (Swift.Result<A.Response, LanguageServerProtocol.ResponseError>) -> () in LanguageServerProtocol.RequestType._handle(_: LanguageServerProtocol.MessageHandler, id: LanguageServerProtocol.RequestID, reply: @Sendable (Swift.Result<LanguageServerProtocol.ResponseType, LanguageServerProtocol.ResponseError>, LanguageServerProtocol.RequestID) -> ()) -> () at <compiler-generated>, state=0x000000012860e330) at SourceKitLSPServer.swift:617 [opt]

Here is the coredump as well: sourcekit-lsp.core.gz

Steps to Reproduce

By simply starting up the LSP with Swift extension in VSCode.

Logging

~/Collection  $ /Library/Developer/Toolchains/swift-LOCAL-2024-06-08-a.xctoolchain/usr/bin/sourcekit-lsp diagnose
sourcekit-lsp diagnose collects information that helps the developers of sourcekit-lsp diagnose and fix issues.
This information contains:
- Crash logs from SourceKit
- Log messages emitted by SourceKit
- Versions of Swift installed on your system
- If possible, a minimized project that caused SourceKit to crash
- If possible, a minimized project that caused the Swift compiler to crash

All information is collected locally.

                                                                                                                        Diagnosing sourcekit-lsp issues
 0% [------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------]
Collecting log messages[1]    17815 segmentation fault   diagnose
ahoppen commented 3 months ago

Synced to Apple’s issue tracker as rdar://129455002

ahoppen commented 3 months ago

This was due to an incompatibility in the Swift standard library shipped with the Swift nightly toolchains that conflicted with the standard library in macOS 14.4 and 14.5. The incompatibility was resolved by https://github.com/apple/swift/pull/74366 and the latest release/6.0 toolchain snapshot from https://www.swift.org/install should contain the fix. Could you try that toolchain?

daagaak commented 3 months ago

I was experiencing this on 6.0-DEVELOPMENT-SNAPSHOT-2024-06-13-a on macOS 14.5, does it need a newer snapshot of the toolchain to be cut first to resolve this?

khng300 commented 3 months ago

This was due to an incompatibility in the Swift standard library shipped with the Swift nightly toolchains that conflicted with the standard library in macOS 14.4 and 14.5. The incompatibility was resolved by apple/swift#74366 and the latest release/6.0 toolchain snapshot from https://www.swift.org/install should contain the fix. Could you try that toolchain?

Thanks. The newest snapshot works.

ahoppen commented 3 months ago

It should be resoled in Swift Development Snapshots after June 18.