Xcode LLDB 中的 13 个奇怪行为

Question

When using expressions(ex. po) in console the debugger strongly retains and does not release objects. The result is that the objects, that would otherwise deinitialize, leak.

Steps to reproduce the issue:

1. Open a new Xcode iOS app project.
2. Create a new class and put a log in deinit.

class Something {
    deinit {
        print("Something deinited")
    }
}

3. Open ViewController.swift, override viewDidLoad and make an instance of the class.

override func viewDidLoad() {
    super.viewDidLoad()

    let object = Something()
    print(object)
}

4. Set a breakpoint just after the object initialization line.
5. Run the app on simulator or device.
6. First time when the execution stops at the breakpoint just click continue and see the deinitialization log from the object instance printed.
7. Verify that the object instance has been successfully deinitialized from the memory using memory graph.
8. Run the app again but this time execute "po object" expression in console.
9. Continue
10. See the absence of deinit log in console.
11. Open memory graph in Xcode and see the Something object leaked.

I wonder if this is a lldb bug or anyone has an idea of what else could this be.

Answer 1

This is not the best behavior, but it's hard to fix. po - ie expr -O -- runs in two parts. It first takes the expression you provide, and runs it through the clang or swift compiler to produce some code that can run in the debugee such that it behaves "as if the expression had been typed in your sources at the point where you are stopped." The result of the last statement in the expression is captured as the value of the expression.

That's the p part. For po , lldb takes the result of that expression and runs another expression to fetch the "object description" of that resultant object.

The first part, which captures something as an escaping result, is what causes the extra retain. Note however, that the "expression" can be anything. For instance, you might call a function that generates an object, in which case the result needs to be retained... We'd have to monkey with the compiler to get it to retain in some cases and not in others, and that goes against the goal of being a faithful representation of the compiler. And lldb doesn't really know what was in the expression, it just submits it to the compiler as text and the compiler figures it out.

TL;DR it's a known issue with no easy solution in the context of the expression parser.

The "workaround" is not to use a fully general expression evaluator to print local variables, which does seem a bit overkill. Fortunately, lldb has a command: frame var (short name v ) that presents the values of variables by reading memory and interpreting it using debug info and the type system directly. lldb can do that w/o changing any state in your program. v is also a lot faster, and more reliable than ginning up a contextually aware expression, compiling and running it. There's a object description variant vo if you need the description string rather than the ivars of the object.