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.

One Reply to “How crash logs lie to you”

  1. See Feedback case 61848:
    include function names for all internal plugins and framework parts

    Years ago we decided to include function names in all plugins to make debugging easier and it helped a lot!

    Please support the case with subscribing/favoriting.

Comments are closed.