Sometimes you get a crash log and start digging through the call stack assuming that what it shows you is The Truth.<\/p>\n\n\n\n
But, it may not be.<\/p>\n\n\n\n
If you strip symbols from your apps then the crash logs you get can be horribly misleading.<\/p>\n\n\n\n
For instance a crash that looks like<\/p>\n\n\n\n
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<\/pre>\n\n\n\nWhere the offset from REALPluginMain is an enormous value is VERY likely NOT correct that the call site was in REALPluginMain<\/p>\n\n\n\n
So why does this happen ?<\/p>\n\n\n\n
The system component that records the stack trace simply looks for symbols that are before the call site and reports those. <\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Exceptions in Xojo however ARE quite accurate.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … <\/p>\n