For me, the debugging experience has tremendously improved with Xcode 15 beta. While po always does nothing in async contexts, at least p works:
(lldb) po frame
(lldb) p frame
(CANyonero.Frame) {
tdiff = 0.22076892852783203
id = 1843
ext = 0
data = 6 values {
[0] = 66
[1] = 146
[2] = 214
[3] = 29
[4] = 128
[5] = 92
}
}
Just want to say that the debugger is broken and my experience is the worst. Apple, please!!!
Just want to say that the debugger is broken and my experience is the worst.
In order to turn this into something actionable, would you mind clarifying what "is broken" means in the context of your project? For example, what exactly doesn't work, what's the output of swift-healthcheck in LLDB, ... ā the more details you can include, the better. If you can share a project that reproduces the problem, that would be ideal.
If you aren't comfortable with sharing details about your project on the forum you could also submit a feedback.apple.com since it sounds like you are using Swift on an Apple platform.
What's the status here? LLDB has been broken for for well over a year. Does Apple not know about this?
For example:
(lldb) p daysRemaining
error: expression failed to parse:
error: <EXPR>:3:1: error: cannot find 'daysRemaining' in scope
daysRemaining
^~~~~~~~~~~~~
frame v indicates the implicit self variable doesn't exist which obviously breaks printing of all variables. The function parameters do print however so indeed self is to be blame.
(App.Subscription) self = <no location, value may have been optimized out>
Did you build in release mode? lldb prints a disclaimer whenever it detects an optimized build that such builds are usually incompatible with commands like frame var, regardless of original source language.
no debug mode of course. Are you guys not getting this too? The self var missing should be optimized away anyways.
Wait, doesnāt that mean this is behaving correctly? If the ABI doesnāt pass self to a function, the debugger has no means of accessing selfās properties while stopped within that function.
If the ABI does pass self, then the compiler should emit code to stash self and the appropriate debug info to retrieve it. If you have a case where that doesnāt happen, thatās worth a GitHub issue.
Can you post more of the surrounding code, or preferably a self-contained file that reproduces the issue? From your description itās not quite clear whether yourāre in a method or in a closure.
Not sure if it's bad form to jump on this thread. I'll be glad to start another if that's better for you.
Since installing Xcode 15, lldb has become unusable for me. The lldb server crashes or gives an error every time I evaluate an expression (e.g., with the po command). I have saved this morning's crash logs here:
https://iterm2.com/misc/lldb-rcp-server-crashes.zip
Steps to reproduce:
po self`The most common failure mode is this:
(lldb) po token
error: Expression evaluation failed. Retrying without binding generic parameters
error: Could not evaluate the expression without binding generic types.
In this case token is an NSObject subclass and there are no generics to be seen for miles.
You get the same error trying to po self on a Swift object.
The v command still works.
I'm severely handicapped without a debugger and I'll help you in any way possible!
I know this is probably not very useful feedback; but Iāve pretty much given up on ever getting any reliable debugging tools for Swift on anything other than the most basic of projects. Xcode generally freezes up to a minute when hitting breakpoints and then when using basic p/po the debugger frequently times out. Our project is several million lines across 30ish modules, so itās a bit bigger than most, but I would still expect better.
I would love a feature freeze on Swift and just a bug fix/debugging tools enhancement/quality of life release.
Thanks for the excellent repro instructions, @gnachman! The crash logs point to the crash fixed in Add missing nullptr check by adrian-prantl Ā· Pull Request #7313 Ā· apple/llvm-project Ā· GitHub, which did not make it into swift 5.9.0 that shipped with Xcode 15.0.
I can post an update here when I have a better understanding about the po error.
Thanks for sharing your experience, @dlbuckley. Would you be willing to capture a trace of LLDB by running
xcrun xctrace record --output ~/Desktop --instrument "os_signpost" --instrument "Time Profiler" --attach lldb-rpc-server --window 5m
in a Terminal right after launching a debug session and running a few slow commands? The output of (lldb) swift-healthcheck at the end of the session would also be useful. It might help us understand what LLDB is spending the time on your case and also potentially point you to workarounds you could apply to your project.
Thanks for the response Adrian and the offer for help. Iāll take a look tomorrow and come back to you with a few examples (Iāll send them in a DM).
Out of curiosity what would be the best place to send this type of report in future? It feels a bit useless and spammy to create a generic performance issue ticket each and every time I, or anyone else, encounter this kind of issue. Is there a better channel for these kinds of reports? Maybe if there was a standard process for reporting them we could start to see some patterns to help prioritise issues.
If the report is about Appleās toolchain, Bug Reporting - Apple Developer, if itās about an open source toolchain, bugs.swift.org (and tag me or LLDB), and/or a forum post to the LLDB topic here.
[edit: fixed URL for apple feedback]
If the report is about Appleās toolchain, Bug Reporting - Apple Developer ,
I don't wan't to beat the same old drum (and it's not your fault at all), but the Apple feedback tool from a users perspective is a useless black box which never gets a reply until several years down the line when you are asked to try again with the latest build (at which point the issue probably still isn't fixed). It's utterly useless for any two way communication to really understand an issue. I've tried many times to give it a chance but i've given up.
Maybe after 14 years of working on Apple platforms and dealing with issues with no fixes for years I've just become jaded 
Full ACK on that. The process is broken and trust me I have lamented a lot about that. But let's please not derail this thread. We need to take every bit of attention from an Apple developer that we can get to improve the tools ;-)
Even though on the whole I totally agree with you re Radar / Feedback, in cases where a specific engineer has asked you to submit one and you give them the FB number, I would expect the outcome to be significantly different to an unsolicited FB report.
Full ACK on that. The process is broken and trust me I have lamented a lot about that. But let's please not derail this thread. We need to take every bit of attention from an Apple developer that we can get to improve the tools ;-)
Indeed!
Even though on the whole I totally agree with you re Radar / Feedback, in cases where a specific engineer has asked you to submit one and you give them the FB number, I would expect the outcome to be significantly different to an unsolicited FB report.
This is the one exception, correct.
@Adrian_Prantl I've sent you a PM with a few example dumps as you requested. This is probably less to do with the swift tools; but one thing that exasperates the bad experience is when you hit a breakpoint and Xcode freezes up for a minute or so but you can't just cancel the breakpoint and continue. You have to wait until Xcode or LLVM is finished doing what it's doing before you can continue. The freezing wouldn't be so bad if you could just cancel the operation and continue right away.
It can be difficult sometimes to know where a bug really belongs. This forum is much more responsive than Apple forums or Feedback Assistant, making me certainly try to find any way I can to justify posting about issues here rather than there.
@Adrian_Prantl I've sent you a PM with a few example dumps as you requested.
Thanks, the traces you collected are indeed very helpful.
You have to wait until Xcode or LLVM is finished doing what it's doing before you can continue. The freezing wouldn't be so bad if you could just cancel the operation and continue right away.
Assuming that what you're waiting on is the variable view, as far as I know stepping is not supposed to be blocked on the variable view. I know you said that you're stuck on an earlier version of Xcode, but if this persists, it might worth a report of its own.