LLDB: Couldn't IRGen expression

IosXcodeLldb

Ios Problem Overview


When I'm running a unit test and want to debug something, I set a breakpoint and type for instance "po myVariable". The response I get from LLDB is:

error: Couldn't IRGen expression, no additional error

Example:

I have the smallest little unit test defined here:

class MyExampleTests: XCTestCase {
    func testLLDB() {
        let world = "World"
        print("Breakpoint goes here")
        print("Hello \(world)")
    }
}

I set my breakpoint in "Breakpoint goes here", and when I run, I do 'po world':

(lldb) po world
error: Couldn't IRGen expression, no additional error

Any suggestions to how I can make it evaluate my expression instead?

Ios Solutions


Solution 1 - Ios

I was having the same issue using Carthage frameworks, and got the LLDB debugger working again by deleting the Carthage folder in the project root and forcing Carthage to rebuild the frameworks from source:

carthage update --platform iOS --no-use-binaries

Solution 2 - Ios

You are likely getting this error because you are setting a breakpoint in another project/framework/module.

Instead of po world, the quickest solution is to use the following command:

fr v world

Solution 3 - Ios

edit:

Since this answer gets some attention, please note that it describes just a quick fix.
If you encounter the problem frequently, check the other answers for a more permanent solution.
For me, cleaning the build folder did the trick.
Edit 2: Cleaning doesn't help in some cases, carthage update --platform iOS --no-use-binaries always does for me.

original answer:

I have a quick and dirty solution that makes this work.

  • select the first accessible frame in your debug navigator, usually mainenter image description here

  • type something in the debugger, for example po self

  • select the original frame in the debug navigator and execute your command, it should work now

I don't know why it works, but it does for me. I just found out by chance.
I'd be interested to hear an explanation from somebody with more insights (I am using Carthage in my project).

Solution 4 - Ios

In my case, I just restarted Xcode, and it's good :)

Solution 5 - Ios

If you are using CocoaPods, this may apply to you. There are two things to make sure of.

Gotcha 1: Make sure you have not added pod dependencies to your Test target(s) in your Podfile:

target 'MyApp' do
  project 'MyApp'

  pod 'Alamofire'
  # ... other pods ...

end

target 'MyAppTests' do
  project 'MyApp'
  inherit! :search_paths
  # Do not add your main app pods here
  # You can use pods for writing your test cases though (e.g. mocks)
end

In my case I had quite a few frameworks and at least one of them was using binaries and caused LLDB to freak out if I added it to my test target.

As a side note/tip, if you need to use any dependencies from within your app, you need to change the runtime behavior of your main app via launch arguments instead of doing things in your testing code. (This is where I strayed from the path and it caused me problems.) You can do this by adding this to your test file:

# When you launch your app (e.g. in `setUpWithError()`)
let app = XCUIApplication()
app.launchArguments = ["testing-enabled"]
app.launch()

and then in your main app code (e.g. in AppDelegate or SceneDelegate):

#if DEBUG
if CommandLine.arguments.contains("testing-enabled") {
    configureAppForTesting()
}
#endif

The #if DEBUG is not necessary but it's good practice to not ship code that will not be executed in the published app.

Gotcha 2: If you have custom build configurations, make sure your tests run in Debug mode.

For example, if we have created a build config called App Store based on Release and a test config based on Debug, then we need to do the following in our Podfile:

target 'MyApp' do # do it for MyAppTests also!
  project 'MyApp', 'App Store' => :release, 'Test' => :debug

  # ... pod dependencies, etc.
end

Without this setting, your dependencies will be built using the default iOS config which is a Release type of configuration (with compiler optimizations for both [Swift][1] and [GCC][2] that the debugger won't like).

Finally, make sure that your scheme's Test mode is set to use the proper build configuration (in this case Test) as in the screenshot below.

![Xcode scheme config screen][3]

[1]: https://help.apple.com/xcode/mac/11.4/#/itcaec37c2a6?sub=dev076ec5661 "Xcode Build Settings Reference: SWIFT_OPTIMIZATION_LEVEL" [2]: https://help.apple.com/xcode/mac/11.4/#/itcaec37c2a6?sub=dev80f5ad208 "Xcode Build Settings Reference: GCC_OPTIMIZATION_LEVEL" [3]: https://i.stack.imgur.com/9Tpvb.png

Solution 6 - Ios

you can try with netx command: Depend where you have install swift, in my case is in /opt/swift/

sudo chmod 644 /opt/swift-3.1.1/usr/lib/swift/CoreFoundation/*

Solution 7 - Ios

CocoaPods Binary (https://github.com/leavez/cocoapods-binary) was causing this problem for me. Ended up removing it to fix the problem.

Solution 8 - Ios

I had the exact same problem because of the Instabug framework.

If you can't find a solution then you should export the LLDB logs by running the log enable lldb expr -f /some/path/to/save/logs command in the debugger and check for failures in that file because that's what helped me.

Also, you should file a bug report on http://bugs.swift.org/ with the LLDB logs attached to it.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionniklassaersView Question on Stackoverflow
Solution 1 - IosJonathan CabreraView Answer on Stackoverflow
Solution 2 - IosnodebaseView Answer on Stackoverflow
Solution 3 - Iosde.View Answer on Stackoverflow
Solution 4 - IosAnton MalmyginView Answer on Stackoverflow
Solution 5 - IosistvanpView Answer on Stackoverflow
Solution 6 - IosJorge Omar MHView Answer on Stackoverflow
Solution 7 - IosFoghView Answer on Stackoverflow
Solution 8 - IosarturgrigorView Answer on Stackoverflow