How crash logs lie to you

Sometimes you get a crash log and start digging through the call stack assuming that what it shows you is The Truth.

But, it may not be.

If you strip symbols from your apps then the crash logs you get can be horribly misleading.

For instance a crash that looks like

Thread 0 Crashed:
0  libsystem_kernel.dylib              0x00007fff6597bfce __pthread_kill + 10
1  libsystem_c.dylib                   0x00007fff658d830a abort + 127
2  libsystem_c.dylib                   0x00007fff658a0360 basename_r + 0
3  XojoFramework                       0x000000010ca2fa79 _Z29ShowDebuggerConnectionFailurev + 0
4  SpawnCompiler.dylib                 0x000000011262b260 REALPluginMain + 934808
5  SpawnCompiler.dylib                 0x0000000112694dfb REALPluginMain + 1367859
6  Xojo                                0x0000000107a430cb DebuggerMap.LookupLineAddress%b%o<DebuggerMap>si8&i8 + 107
7  Xojo                                0x000000010a207ac5 StudioDebuggerUI.StudioDebuggerUI.LookupBreakpointAddress%i8%o<StudioDebuggerUI.StudioDebuggerUI>si8 + 421

Where the offset from REALPluginMain is an enormous value is VERY likely NOT correct that the call site was in REALPluginMain

So why does this happen ?

The system component that records the stack trace simply looks for symbols that are before the call site and reports those.

If symbols have been stripped then you see the problem. That crash logger cannot find the “correct” symbol and so may simply walk back a long long way to find one that hasnt been stripped. It reports that + a really large offset.

Exceptions in Xojo however ARE quite accurate.