Yo Apple: Xcode debugging Swift is *STILL* horribly broken

Makes me – again – ponder whether those working on the tools are actually using them… else these big issues couldn‘t have lingered for months.

7 Likes

The issue isn't only that they may not use the same tools we do, but that they're used to them being broken, since internal builds are even more unstable than what we see. It's a vicious cycle exacerbated by the tools being on the same release timeline as the things they're building.

5 Likes

I second that. When I started developing for iOS platform in Objective C I was really impressed with the tooling. It was very robust, fast and reliable. Then Swift was introduced, which is a great language, but the debugger provided with the IDE have never been close to the quality of ObjC debugger.

It's going to be a decade soon and I basically gave up hoping that it'll get somewhere. So often I just resort to print debugging because waiting for the tools to load and crash or tell me they don't recognize variables in scope is just too much. For a moment I was thinking I'm doing something wrong, but threads like these convince me otherwise. And I'm working in projects that are yet to adopt any modern Swift features like await-async.

10 Likes

The biggest issue I have is that nothing seems to work until you disable System Integrity Protection, and Xcode never tells you this is why. Unable to acquire required task port is not an informative error message. The message should say why it's not working.

You can easily ask the system if SIP is enabled, Xcode could check.


Anyway, I would like to add these to the list of complaints:

  • The console can't understand ansi escape codes, so for example my colored error output looks wrong.
  • Trying to debug parallel code is annoying because it keeps jumping between threads by default
  • Constantly restarting my laptop with security disabled every time I need the debugger is tedious, but this is mostly just a macOS issue.

Just a guess, but maybe the debugging tools not working is somehow related to using classes?

2 Likes

This... shouldn't at all be necessary. These days, you shouldn't need to disable SIP for pretty much anything (unless you're really looking to hack around on your own system in otherwise unsafe ways). I don't have any specific tips for you (beyond the usual troubleshooting — “have you tried reinstalling dev tools?”, “in what contexts does this happen?”, “are you seeing this with dev tools outside of Xcode?”, etc.), but just a heads-up that this is not the expected, or desired, workflow for debugging.

5 Likes

Agreed. The specific message “Unable to acquire required task port” should only appear when trying to attach a debgger to a system process, or when trying to attach to a process running as another user without running the debugger as root.

I am not debugging apps but rather Swift packages. It works for iOS apps, yes, but to debug memory of anything that isn't an app it does not work.

I have completely reinstalled macOS at one point (for a different reason) but this issue did not go away.

Surely you can understand why reading random processes’ memory is disabled by default. Though I’m curious what processes you’re attaching to?

Yes, I am not trying to attach to some random process, I mean running a package with command + R directly from Xcode.

Interesting. The reason you don’t hit this for apps is likely because Xcode automatically adds a “get-task-allowed” entitlement to the build product. I wonder if this is something which should be added to the SwiftPM integration, or perhaps to SwiftPM itself to support non-IDE debugging. It’s definitely not good for a basic development workflow to encourage disabling SIP!

1 Like

I just run into this too:

1 Like

I think this may be straying a bit off-topic for the forums, but I'd be curious about your specific setup here. I'm able to create an executable target in a Swift package and run and debug on macOS just fine in Xcode (just by hitting R), without disabling SIP. If you're able to create a standalone reproducing package, it'd be great for investigation!

Weird, maybe it's a difference between arm and intel Macs? The arm ones seem to have more strict security in general. Are you trying this on an intel Mac by any chance? If not, I have no idea what the reason might be.

This is happening for any package, there is no specific package that causes this.

No, I'm running on a 2021 MBP with an M1 Pro. I've got Xcode installed through Xcodes (so downloaded directly from the Apple dev site rather than via the App Store), installed to /Applications (so, my internal drive and not an external one). I don't believe these factors should make a difference, but mentioning just in case.

In any case, I bring this all up to say that to the best of my (possibly-limited) knowledge, you shouldn't need to disable SIP for any code you build and run through Xcode, assuming everything is working as intended (which it appears not to be for you, whatever the reason).

It occurs to me that the toolchain folks aren’t actually using the tools…on Swift. My impression is that they work much better on Clang output, and the Swift compiler, LLVM, and LLDB are all written in C++. Beyond their testing, they probably aren't immersed in Swift development.

But so many folks at Apple actually do write Swift code day-in and day-out, it’s astonishing to me that the toolchain folks haven't heard more about this. When I was at Apple, if you ran into an issue in the Apple codebase, you messaged someone working on that code base directly about it. This has been broken for years. Some of my bugs on this go back to 2015. It’s astonishing to me that it’s still as bad as it is.

9 Likes

my observation is that lldb breaks exactly this way every fall. usually its partially fixed by christmas. its never completely reliable. this is the worst its been in several years. ymmv of course.

4 Likes

To close the loop here, I tracked down the code change that fixes the issue reported by @JetForMe in the 5.8 branch as Fix IRGen debug info for swift_task_alloc'ed variables. by adrian-prantl · Pull Request #62542 · apple/swift · GitHub .

Please continue filing bugreports with reproducers when you encounter issues, it makes a big difference! Thanks!

14 Likes

I wish the 5.8 toolchain worked in Xcode.

2 Likes

Since it is a bug, is there any chance of back porting the fix into 5.7? Do we really want to wait until WWDC next year for a fix?

That's not a question directed at you but to the Swift people generally.

1 Like

I tried again with the 1/30 5.8 toolchain build. It sorta works, and does seem to do much better allowing me to inspect variables (but I still can't step through async code). But there are issues I've expanded on here.

And the fix is tiny, I would hope it could be back-ported to 5.7!