debugging-instrumentslisted

# Debugging and Instruments Keep interactive graph and Instruments triage here. Route detailed `.memgraph` command-line ownership/growth analysis and ETTrace work to their focused skills. ## Contents - [LLDB Debugging](#lldb-debugging) - [Memory Debugging](#memory-debugging) - [Hang Diagnostics](#hang-diagnostics) - [Build Failure Triage](#build-failure-triage) - [Instruments Overview](#instruments-overview) - [Common Mistakes](#common-mistakes) - [Review Checklist](#review-checklist) - [References](#references) ## LLDB Debugging Start with a small, repeatable workflow: 1. Reproduce in a Debug build and stop at the narrowest useful breakpoint. 2. Inspect locals without executing code, then capture the current stack. 3. Move to the relevant frame or thread and verify the failing state. 4. Add a condition or watchpoint only when the bad transition is still unclear. ```text (lldb) br set -f ViewModel.swift -l 42 # Stop at file and line (lldb) v myLocal # Inspect without executing code (lldb) po myObject # Use debugDescription when needed (lldb) bt all # Capture every thread's backtrace (lldb) frame select 3 # Inspect a relevant frame (lldb) br modify 1 -c "count > 10" # Narrow a noisy breakpoint (lldb) w set v self.score # Stop on an unexpected write ``` Use `v` over `po` when you only need a local variable value — it does not execute code and