{"id":654,"date":"2023-04-28T15:05:58","date_gmt":"2023-04-28T13:05:58","guid":{"rendered":"https:\/\/mic.st\/blog\/?p=654"},"modified":"2023-05-15T21:30:47","modified_gmt":"2023-05-15T19:30:47","slug":"fix-broken-lldb-in-xcode","status":"publish","type":"post","link":"https:\/\/mic.st\/blog\/fix-broken-lldb-in-xcode\/","title":{"rendered":"Fix LLDB issues in Xcode"},"content":{"rendered":"\n

Did you ever encounter some strange issues when dealing with broken LLDB in Xcode leaving print()<\/code>as your final idea? Welcome to broken Xcode tooling.<\/p>\n\n\n\n

TLDR; or answer the title’s question: <\/strong>
Actually, I have no idea how to really fix it. For keeping your sanity, just use print()<\/code>whenever LLDB seems broken.<\/p>\n\n\n\n

But let me explain or let’s look at the symptoms first:<\/p>\n\n\n\n

Especially in async<\/code> contexts LLDB seems really broken. You often get stuff like this:<\/p>\n\n\n

error: expression failed to parse:\nerror: <EXPR>:8:1: error: cannot find 'destinationURL'<\/span> in<\/span> scope\ndestinationURL\n^~~~~~~~~~~~~~<\/code><\/span>Code language:<\/span> Bash<\/span> (<\/span>bash<\/span>)<\/span><\/small><\/pre>\n\n\n
If you are think using fr v<\/code> or v<\/code> might work here: <\/p>\n\n\n\n
Haha, no.<\/p>\n\n\n
(lldb) v destinationURL\n(Foundation.URL) destinationURL = <no location, value may have been optimized out><\/code><\/span>Code language:<\/span> Bash<\/span> (<\/span>bash<\/span>)<\/span><\/small><\/pre>\n\n\n
In some cases the part using v<\/code> or fr v<\/code> might work but that is not the point here. Nobody can work with debugging tools that give ambiguous results or often don’t work. <\/p>\n\n\n\n
forum.swift.org indicating brokenness <\/h2>\n\n\n\n
It seems to be an ongoing problem for Xcode or the tools it contains. I stumble across it now and then, regardless of whether it’s some strange Swift package manager of LLDB behavior. Often I ended up in some forum.swift.org thread. Actually, I learned whenever landing in some forum.swift.org thread while googling for anything Xcode \/ Swift related it seems to be a bigger issue.<\/p>\n\n\n\n
E.g. when googling for broken LLDB stuff I ended up here: https:\/\/forums.swift.org\/t\/yo-apple-xcode-debugging-swift-is-still-horribly-broken\/62702\/62<\/a>). The essential learning in this case: There are plenty of people reporting bugs already, Apple doesn’t seem to care too much or they were unable to fix ongoing issues for years. Best things you can do is report more bugs, just don’t care or go on with your life and use some other technique while waiting for the next Xcode.<\/p>\n\n\n\n
For this specific case of broken LLDB, I recommend to just use print()<\/code> in strange cases like this. Trying to fix broken Xcode is often a waste of time and energy from my experience. Similar to how it often makes a project build again by deleting Derived Data<\/code> and restarting Xcode. It’s sad but that’s what you have to deal with.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
I am aware that some people never use LLDB and only ever use print()<\/code>for debugging. Then everything is fine for you anyway. However, personally having to print everything out really slows my debugging down a lot. First, you have to add the statements, then you have to change them over and over again (e.g. you wanted to look at something else you do realize later, you missed something, etc.).<\/p>\n\n\n\n
LLDB in Xcode is still broken after all these years. The thread linked above is not like years old, the last entry is from March 2023.<\/p>\n\n\n\n
Just fall back to print()<\/code> to keep your sanity when LLDB does not work (again).<\/p>\n","protected":false},"excerpt":{"rendered":"
Did you ever encounter some strange issues when dealing with broken LLDB in Xcode leaving print()as your final idea? Welcome to broken Xcode tooling. TLDR; or answer the title’s question: Actually, I have no idea how to really fix it. For keeping your sanity, just use print()whenever LLDB seems broken. But let me explain or…<\/p>\n","protected":false},"author":1,"featured_media":668,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[3],"tags":[57,58,15],"class_list":["post-654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ios-development","tag-lldb","tag-tooling","tag-xcode"],"_links":{"self":[{"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/posts\/654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/comments?post=654"}],"version-history":[{"count":18,"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/posts\/654\/revisions"}],"predecessor-version":[{"id":730,"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/posts\/654\/revisions\/730"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/media\/668"}],"wp:attachment":[{"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/media?parent=654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/categories?post=654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mic.st\/blog\/wp-json\/wp\/v2\/tags?post=654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}