How do the malloc debugging environment variables (such as MallocScribble) expose uninitialised and freed memory, and when do they beat ASan?

The system allocator can be asked to make misuse obvious. MallocScribble=1 fills freed blocks with 0x55 and fresh allocations with 0xaa; MallocPreScribble fills new blocks; MallocGuardEdges puts guard pages around large blocks; and MallocStackLogging (Q457) records allocation stacks. They need no rebuild: set them in the scheme or the shell. In the check, a freshly allocated 64-byte buffer reads aa aa aa aa under MallocScribble=1, so code that reads uninitialised memory suddenly fails in a way that is reproducible instead of sometimes holding zeros.

Use them when you cannot rebuild with ASan (a prebuilt framework, a third-party binary) or when ASan’s cost hides a timing bug. They are much weaker: scribbling only helps when the poisoned value changes behaviour, and guard pages catch overruns only of large blocks. Behaviour of freed small blocks is allocator-dependent (the first bytes may hold allocator metadata), so I only assert the fresh-allocation pattern. For Swift value types you rarely need this; it matters with unsafe pointers and C.