Trying to solve Alamofire's lldb woes

For years now lldb has been unable to print Alamofire's *Response type in completion handlers, even when other values in other completion handlers are okay. Naturally this makes debugging while developing Alamofire quite frustrating. I'd like some help narrowing down the cause so I can either make a better bug report to get it fixed or look into fixing it myself.

The issues is trivially reproducible. Clone Alamofire, place a break point in a completion handler of one of our tests, and run the test. Attempting to print the response will produce this error:

error: Couldn't materialize: can't get size of type
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression

Of course I can frame variable or ex debugPrint(response) to see the value, but this affects both po and the variable view, so it would be much more convenient to actually be able to print.

I've tried all of the workaround I could find online, including:

  • Ensuring optimizations are turned off.
  • Turning optimizations on just to see.
  • Setting the Debug Information Format to DWARF or DWARF with dSYM file.
  • Toggling various combinations of sanitizers and other settings in the scheme.

Nothing has made any difference, so what are my next steps to try and debug this?

1 Like

I'm motivated to help you fixing this, as I understand your frustration. Ideally a smaller, self contained testcase would help. As in, something I can run myself from the command line that reproduces this bug. Can you try?

It's also interesting that frame var works for you, but the variable view doesn't, as they use the same underlying mechanism to resolve types.

Sorry, it doesn't look like frame var actually works, as it just has this for the response:

(Alamofire.AFDataResponse<Any>) resp = {
  request = nil

This is odd, as the request has far more properties, and the request property isn't nil, as can be seen by manually printing the value:

(lldb) e debugPrint(resp)
[Request]: GET
[Request Body]: 
[Status Code]: 200
Access-Control-Allow-Origin: *
Content-Length: 432
Content-Type: application/json
Date: Wed, 25 Mar 2020 20:55:05 GMT
Server: gunicorn/19.9.0
access-control-allow-credentials: true
[Response Body]: 
  "args": {}, 
  "headers": {
    "Accept": "*/*", 
    "Accept-Encoding": "br;q=1.0, gzip;q=0.9, deflate;q=0.8", 
    "Accept-Language": "en-US;q=1.0", 
    "Host": "", 
    "User-Agent": "Unknown/Unknown (; build:16091; macOS 10.15.4) Alamofire/5.0.5", 
    "X-Amzn-Trace-Id": "Root=1-5e7bc529-c49fdc85edf9c9986b493081"
  "origin": "", 
  "url": ""

[Data]: 432 bytes
[Network Duration]: 0.30299103260040283s
[Serialization Duration]: 0.0028259754180908203s
[Result]: success({
    args =     {
    headers =     {
        Accept = "*/*";
        "Accept-Encoding" = "br;q=1.0, gzip;q=0.9, deflate;q=0.8";
        "Accept-Language" = "en-US;q=1.0";
        Host = "";
        "User-Agent" = "Unknown/Unknown (; build:16091; macOS 10.15.4) Alamofire/5.0.5";
        "X-Amzn-Trace-Id" = "Root=1-5e7bc529-c49fdc85edf9c9986b493081";
    origin = "";
    url = "";
() $R1 = {}

I can try to produce a smaller test case, but completion handlers usually work.

Can you provide the definition of Response and Request?
I would like to see if there's anything particular with them [e.g. resilient types]. Other than that, I guess I should just try to find the time to sit down and debug this.

DataRequest - Note: this is a subclass.


Is there any way I could help in debugging this? Perhaps gathering diagnostic info from Xcode or lldb while I'm debugging?

I think the best you can do -- if you can, is provide a smaller testcase where this reproduces. [hopefully, a single file]

I was never able to reproduce this in a small sample, but my testing in Xcode 12 seems to indicate the issue may have been fixed by the enhancements to lldb in that version. For the first time in literally years I can use the debugger in Alamofire's completion handlers!

1 Like

Hi @Jon_Shier I was super excited to see this message, installed Xcode 12 to test it with our project target but for us debug is completely broken. Could you please let me know how you've been able to confirm that the Alamofire debugging issues have been fixed on Xcode 12?

I only tested that debugging Alamofire itself from within its test cases works. If you're still having trouble debugging Alamofire while its integrated into your project, you should report that issue to Apple. I'll do some additional testing to confirm.


I've confirmed that debugging works in a simple project that integrates Alamofire using CocoaPods.

Thanks for checking, in my case it is just no output at all unfortunately!

I should add this is not Alamofire related though, it happens to anything that I try to inspect. Will file a radar!

I can confirm this behavior: po response prints the response properly, while frame variable has a broken result value.

Edit: It's also strange it says the request value is nil. That seems unlikely if you have a response value.

You know I hadn't even noticed that until you mentioned. That's really strange!

I'm guessing that the issue where request is reported as nil is a manifestation of SR-12724.

That may also explain result's <invalid> (0x0) value, as a nil Result would be invalid.

Basically almost all types from Foundation don't work. And po usually works and frame v usually doesn't work.

Terms of Service

Privacy Policy

Cookie Policy