Debugging stack traces

  • Hi all,

    When I get a stack trace in a crash report, as exampled below, can I use the offsets (+71, +50) to locate the relevant line in the source code? What do these numbers actually mean?

    1  com.apptree.drawkit               0x001c7bb9 -[DKDrawableObject encodeWithCoder:] + 71
    2  com.mapdiva.ortelius             0x0003c81d -[DKOSymbol encodeWithCoder:] + 50

    --Graham
  • On Dec 2, 2009, at 4:55 PM, Graham Cox wrote:

    > When I get a stack trace in a crash report, as exampled below, can I use the offsets (+71, +50) to locate the relevant line in the source code? What do these numbers actually mean?

    They're byte offsets from the start of the function, in the machine code.

    I don't know of a good way to convert these back into line numbers. If you have that exact same version of the code open in Xcode (including configuration and architecture) you can choose Build > Show Assembly Code, then look for the function in the assembly; there are ".line" directives that show source line numbers, but unfortunately that listing doesn't show byte offsets. Or you can use otool to disassemble the function out of the binary, which includes the offsets but not the line numbers. :/

    If you manage to solve that, you then have the lesser problem that optimized code is often heavily rearranged from the way it looks in the source, so the line numbers may not make much sense.

    —Jens
  • On Dec 2, 2009, at 4:55 PM, Graham Cox wrote:
    > When I get a stack trace in a crash report, as exampled below, can I use the offsets (+71, +50) to locate the relevant line in the source code? What do these numbers actually mean?
    >
    > 1  com.apptree.drawkit               0x001c7bb9 -[DKDrawableObject encodeWithCoder:] + 71
    > 2  com.mapdiva.ortelius             0x0003c81d -[DKOSymbol encodeWithCoder:] + 50

    That's the offset in bytes of the CPU instruction in that function - the crashing instruction in the top frame, and the instruction after the call in the other frames.

    You can recover the line number if you have the binary and dSYM file that match the version from the crash.

    (The values below are all fake.)

    1. Find the binary's UUID in the Binary Images section of the crash log.
        Binary Images:
            0x1000 -    0x1ff7 +com.apptree.drawkit ??? (???) <A84E261F-B98E-8ECD-3A40-24C65353BE3E> /path/to/DrawKit.framework/Contents/MacOS/DrawKit

    2. Find the binary for the version with that UUID.
        % dwarfdump -u /path/to/DrawKit.framework
        UUID: D0358F4B-FCBB-321A-5F9E-E4C36C20ADE9 (x86_64) /path/to/DrawKit.framework/Contents/MacOS/DrawKit
        UUID: A84E261F-B98E-8ECD-3A40-24C65353BE3E (i386) /path/to/DrawKit.framework/Contents/MacOS/DrawKit

    3. Find the dSYM file with that UUID. A Spotlight search for the UUID may work.
        % dwarfdump -u /path/to/DrawKit.framework.dSYM
        UUID: D0358F4B-FCBB-321A-5F9E-E4C36C20ADE9 (x86_64) /path/to/DrawKit.framework.dSYM/Contents/Resources/DWARF/DrawKit
        UUID: A84E261F-B98E-8ECD-3A40-24C65353BE3E (i386) /path/to/DrawKit.framework.dSYM/Contents/Resources/DWARF/DrawKit

    4. Run gdb with that architecture, binary, and dSYM.
        % gdb -arch i386 /path/to/DrawKit.framework
        (gdb) add-dsym /path/to/DrawKit.framework.dSYM

    5. Ask gdb for the line number for that function+offset. (Note the actual address may not match the one in the crash log.)
        (gdb) x/i '-[DKDrawableObject encodeWithCoder:]' + 71
        0x4bb9 <-[DKDrawableObject encodeWithCoder:]+71> ...
        (gdb) info line *0x4bb9
        Line 55 of "DKDrawableObject.m" starts at address 0x4bb9 <-[DKDrawableObject encodeWithCoder:]+71> and ends at 0x4bc9 <-[DKDrawableObject encodeWithCoder:]+87>

    --
    Greg Parker    <gparker...>    Runtime Wrangler
  • Thanks! That's pretty cool, and very comprehensive.

    --Graham

    On 03/12/2009, at 12:21 PM, Greg Parker wrote:

    > That's the offset in bytes of the CPU instruction in that function - the crashing instruction in the top frame, and the instruction after the call in the other frames.
    >
    > You can recover the line number if you have the binary and dSYM file that match the version from the crash.
    >
    > (The values below are all fake.)
    >
    > 1. Find the binary's UUID in the Binary Images section of the crash log.
    > Binary Images:
    > 0x1000 -    0x1ff7 +com.apptree.drawkit ??? (???) <A84E261F-B98E-8ECD-3A40-24C65353BE3E> /path/to/DrawKit.framework/Contents/MacOS/DrawKit
    >
    > 2. Find the binary for the version with that UUID.
    > % dwarfdump -u /path/to/DrawKit.framework
    > UUID: D0358F4B-FCBB-321A-5F9E-E4C36C20ADE9 (x86_64) /path/to/DrawKit.framework/Contents/MacOS/DrawKit
    > UUID: A84E261F-B98E-8ECD-3A40-24C65353BE3E (i386) /path/to/DrawKit.framework/Contents/MacOS/DrawKit
    >
    > 3. Find the dSYM file with that UUID. A Spotlight search for the UUID may work.
    > % dwarfdump -u /path/to/DrawKit.framework.dSYM
    > UUID: D0358F4B-FCBB-321A-5F9E-E4C36C20ADE9 (x86_64) /path/to/DrawKit.framework.dSYM/Contents/Resources/DWARF/DrawKit
    > UUID: A84E261F-B98E-8ECD-3A40-24C65353BE3E (i386) /path/to/DrawKit.framework.dSYM/Contents/Resources/DWARF/DrawKit
    >
    > 4. Run gdb with that architecture, binary, and dSYM.
    > % gdb -arch i386 /path/to/DrawKit.framework
    > (gdb) add-dsym /path/to/DrawKit.framework.dSYM
    >
    > 5. Ask gdb for the line number for that function+offset. (Note the actual address may not match the one in the crash log.)
    > (gdb) x/i '-[DKDrawableObject encodeWithCoder:]' + 71
    > 0x4bb9 <-[DKDrawableObject encodeWithCoder:]+71> ...
    > (gdb) info line *0x4bb9
    > Line 55 of "DKDrawableObject.m" starts at address 0x4bb9 <-[DKDrawableObject encodeWithCoder:]+71> and ends at 0x4bc9 <-[DKDrawableObject encodeWithCoder:]+87>
    >
    >
    > --
    > Greg Parker    <gparker...>    Runtime Wrangler
    >
    >
  • On 12/3/09 11:55 AM, Graham Cox said:

    > When I get a stack trace in a crash report, as exampled below, can I use
    > the offsets (+71, +50) to locate the relevant line in the source code?
    > What do these numbers actually mean?
    >
    > 1  com.apptree.drawkit               0x001c7bb9 -[DKDrawableObject
    > encodeWithCoder:] + 71
    > 2  com.mapdiva.ortelius             0x0003c81d -[DKOSymbol
    > encodeWithCoder:] + 50

    In case you haven't see it, this has good info too:
    <http://developer.apple.com/mac/library/technotes/tn2004/tn2123.html>

    And this tool is helpful:
    <http://www.softedge.se/Softedge/dSymbolizer.html>

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
previous month december 2009 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today