Makes me – again – ponder whether those working on the tools are actually using them… else these big issues couldn‘t have lingered for months.
10 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.
7 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.
16 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.
6 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.
1 Like
Surely you can understand why reading random processes’ memory is disabled by default. Though I’m curious what processes you’re attaching to?
1 Like
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!
4 Likes
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!
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.
13 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!
21 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.
2 Likes
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!
If Apple follows their pattern from the last 5 years, 5.8 should be released with the Xcode update in March.
Apple sent back one of my bugs on this issue (FB11236399) saying to test it against Xcode 14.2 beta. It is still just as broken as ever, which tells me Apple doesn't actually attempt to reproduce and test bugs in-house.
7 Likes
On the flip side of that, I did get one back that WAS resolved (an issue where Swift Previews would fail to work if you a Package with an executable target). I suspect that they don't vet their solutions against every feedback, but in my case they did - or they fixed someone else's issue that was close enough that my bug was resolved.
(thank you Xcode team!)
1 Like
Good to hear that. My experience is rarely that. It's usually like the one I reported above. I'm expected to identify it, diagnose it, make a simple reproducible test case, then verify it after they claim it's fixed, and it's, more often than not, not fixed.
10 Likes