vscode-swift icon indicating copy to clipboard operation
vscode-swift copied to clipboard

Debugging swift testing tests fails to attach

Open adam-fowler opened this issue 1 year ago • 10 comments
trafficstars

Describe the bug If I try to debug a swift testing test the debugger fails to attach to the process.

A dialog opens with the following text

process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))

To Reproduce Steps to reproduce the behavior:

  1. Open project with swift-testing tests
  2. Run debug tests

Expected behavior You should be able to test swift-testing tests

Environment

  • OS: macOS 15.0
  • Swift version: Apple Swift version 6.0 (swiftlang-6.0.0.9.10 clang-1600.0.26.2)
  • Visual Studio Code version: 1.94.2
  • vscode-swift version: 1.11.3

This is the debug console output

Console is in 'commands' mode, prefix expressions with '?'. Launching: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/libexec/swift/pm/swiftpm-testing-helper --test-bundle-path /Users/adamfowler/Developer/server/soto-project/soto-cognito-authentication-kit/.build/arm64-apple-macosx/debug/soto-cognito-authentication-kitPackageTests.xctest/Contents/MacOS/soto-cognito-authentication-kitPackageTests --testing-library swift-testing --enable-swift-testing --event-stream-version 0 --event-stream-output-path /var/folders/6v/zhyq15kx1fz1d9hjv1zq9n8c0000gn/T/vscodemkfifo-1729201780878 --filter SotoCognitoAuthenticationKitTests.* -Xswiftc -diagnostic-style=llvm

Minimal diagnostic bundle

adam-fowler avatar Oct 17 '24 21:10 adam-fowler

I think this may be a duplicate of https://github.com/swiftlang/vscode-swift/issues/1089.

plemarquand avatar Oct 18 '24 18:10 plemarquand

How come we are using swiftpm-testing-helper to run the swift-testing executables? I thought you could run the swift testing executables directly. Did this change?

adam-fowler avatar Oct 19 '24 14:10 adam-fowler

(I accidentally posted the response to this on the wrong issue (#1148), moving here)

Its there to support a single binary test product for projects that contain both XCTest and swift-testing tests. More information here: https://github.com/swiftlang/swift-package-manager/pull/7766

More context on the swiftpm-testing-helper from @grynspan:

So, on Linux and Windows, the test product is a flat executable and runs directly. SwiftPM emits a main() function into the executable that calls into XCTest or into Swift Testing depending on what arguments are passed. There is no helper executable needed.

Now, one of our second-tier goals with Swift Testing was for it to share as much logic as possible across platforms. So on all platforms regardless of what kind of test product is produced, the main() function Swift Testing emits into the binary is identical.

However, on Darwin, the test product expected by XCTest is a loadable, but not executable, bundle. The main() function from such a bundle cannot be directly executed—it's just another exported symbol in a library, after all.

Xcode includes an executable, aptly named xctest, that knows how to open these bundles, find XCTest tests, and run them. (There are also other ways to run tests via Xcode but they're not relevant to SwiftPM.) XCTest doesn't use the main() function at all! It also doesn't know anything about Swift Testing or how to discover or run its tests.

Enter swiftpm-testing-helper: it loads an arbitrary loadable bundle/library, finds its main() function, and calls it. It does nothing else. The main() function, being emitted into the test product exactly the same for Darwin as for Linux and Windows, takes over and runs Swift Testing tests.

In a perfect world, Darwin would let us make .xctest bundles both loadable and executable, and we wouldn't need the helper, but for other unrelated reasons that would be a terrible and dangerous idea, so them's the breaks.

plemarquand avatar Oct 21 '24 13:10 plemarquand

Debugging unit tests in VSCode (Cursor) was working fine for me yesterday, and was reliable prior to that. I upgraded to macos 15.4 and Xcode 16.2. Now I get the error described above when trying to debug.

In the console, I can see this error:

macOSTaskPolicy: (com.apple.debugserver) may not get the task control port of (sh) (pid: 44864): (sh) is hardened, (sh) doesn't have get-task-allow, (com.apple.debugserver) is a declared debugger(com.apple.debugserver) is not a declared read-only debugger

cuberoot avatar Apr 04 '25 00:04 cuberoot

Doesn't appear to be the same issue @cuberoot. I believe @plemarquand is taking a look.

grynspan avatar Apr 04 '25 13:04 grynspan

The error message suggest LLDB is told to debug the shell (sh) which doesn't sound right.

@cuberoot can you confirm whether you're using CodeLLDB or lldb-dap for debugging? The Swift extension has a checkbox to use the latter, which comes with the toolchain. If the issue reproduces with both, it's likely VS Code telling us to debug the wrong program, if it reproduces with just one DAP server, it's likely a bug in that implementation. If it's lldb-dap doing the wrong thing, I can help investigate.

JDevlieghere avatar Apr 04 '25 16:04 JDevlieghere

@cuberoot Are you using Swiftly? I managed to reproduce what you're seeing by explicitly setting the "swift.path" VS Code extension setting to the swiftly directory in my home path (i.e: /Users/plemarquand/.swiftly/bin/). However if I remove this setting I am able to debug as expected.

plemarquand avatar Apr 04 '25 20:04 plemarquand

Yes, I am using swiftly. I will look into whether that's an issue... Thanks!

cuberoot avatar Apr 04 '25 21:04 cuberoot

Confirmed. I did:

swiftly use -p

Then I pasted the resulting path + /usr/bin into swift.path. I then restarted and I can debug tests again. So, it looks like VSCode was trying to debug the sh process that was running the swiftly wrapper script.

cuberoot avatar Apr 07 '25 04:04 cuberoot

@cuberoot Good news! FWIW you shouldn't have to set swift.path to anything, as swiftly will handle setting the toolchain for the system and VS Code will pick that up automatically.

plemarquand avatar Apr 07 '25 13:04 plemarquand