Clang has this useful tool called Thread Sanitizer that can detect data races in a program and Xcode makes it easy to use it by providing the “Thread Sanitizer” checkbox in the scheme’s Diagnostics page for Run and Test actions. I needed to run an iOS program with the TSan to see if it would find anything. It did, but all the stracktraces showed only <null>s instead of all symbols, so they weren’t at all clear. I’ve found a workaround how to see that information using breakpoints.
Here’s what I see in the console output when an issue is found:
A runtime issue breakpoint is too broad because it also stops on other errors. What you need is to add a symbolic breakpoint for __tsan_on_report in Xcode, or in LLDB:
123456
(lldb) breakpoint set -b __tsan_on_report
Breakpoint 10: where = libclang_rt.tsan_iossim_dynamic.dylib`__tsan_on_report, address = 0x00000001023c2a20
(lldb) b
Current breakpoints:
10: name = '__tsan_on_report', locations = 1, resolved = 1, hit count = 0
10.1: where = libclang_rt.tsan_iossim_dynamic.dylib`__tsan_on_report, address = 0x00000001023c2a20, resolved, hit count = 0
Now you’ll see those symbolicated stacktraces, at least for the thread where the data race is actually happening. I think you can enhance the breakpoint by automatically printing the thread’s backtrace and continuing the program if you only want to see what data races there are without inspecting each one in the debugger.
ps. I later found that Xcode also shows these runtime issues in the project’s Issue Navigator (Cmd+5), “Runtime” section.