23.3 · Sanitizers, and bugs that only appear in Release
Some bugs are silent: memory corruption that happens to work, races that only lose once in a thousand runs, checks that exist only in debug builds. Sanitizers and a clear idea of what each build mode removes turn those into reproducible failures.
Mental model. Make the invisible bug loud: instrument the build so the bad access, the race or the broken invariant fails immediately and at the cause.
Sanitizers
Address, undefined-behaviour and thread tools, and the checkers built into the OS.
- What do the Address, Thread and Undefined Behavior sanitizers catch, what do they cost, and when do you use them in Swift code?
Sanitizers instrument your build so that certain bugs are detected at the moment they happen, with a report naming both the access and the allocation or other…
Debug versus Release
What optimisation removes, and how to debug what only fails in Release.
- Why do some bugs appear only in Release builds, how do assert, precondition and fatalError differ, and how do you debug an optimised build?
A Release build changes your program in ways a Debug build does not. The optimiser reorders, inlines and removes code, so a race or an uninitialised value that…
More in Debugging & Instruments
- 23.1 · LLDB and breakpoints
- 23.2 · The view debugger, network inspection and memory bugs
- 23.4 · Unified logging: Logger, levels, privacy and reading logs back
- 23.5 · Crash reports, symbolication and a production diagnostics pipeline
- 23.6 · Console, sysdiagnose and reproducing a bug
- 23.7 · Schemes, test plans, simulators and derived data
- 23.8 · Reading sanitizer output, exit codes and runtime traps
- 23.9 · Diagnosing a hang, malloc debugging and leaks from the command line
- 23.10 · Demangling, atos and empty dSYMs, and log formatting