Start traces with CrashReporter

  • Hi,

    Is there any way to make CrashReporter show stack frame content and
    line numbers instead of signatures and offsets? Maybe a way to make
    gdb automatically attach to crashing processes and do a "t a a bt f"
    on them?

    Thanks,
      jules
  • It already does it if debug symbols are available.

    For example:

    3  libnspr.4.dylib                           0x00090636 PR_CreateFileMap + 0
    (prmmap.c:52)
    4  libnss.3.dylib                           0x002b9601
    PK11_GetInternalKeySlot + 74 (pk11slot.c:1659)
    5  org.shadowlab.MyLibrary             0x00052b5f -[KIService
    createCertificate:] + 142 (KIService.m:46)
    6  org.shadowlab.MySoftware          0x00002b9d -
    [MKIAuthorityDocument editorDidEnd:result:context:] + 193
    (MKIAuthorityDocument.m:54)
    7  com.apple.AppKit                     0x964ea233 -[NSApplication
    endSheet:returnCode:] + 288
    8  org.shadowlab.MySoftware          0x00007578 -[WBWindowController
    close:] + 140 (WBWindowController.m:62)
    9  org.shadowlab.MySoftware          0x00004086 -[MKIRequestEditor
    ok:] + 660 (MKIRequestEditor.m:206)

    Le 23 janv. 09 à 19:45, Jules Colding a écrit :

    > Hi,
    >
    > Is there any way to make CrashReporter show stack frame content and
    > line numbers instead of signatures and offsets? Maybe a way to make
    > gdb automatically attach to crashing processes and do a "t a a bt f"
    > on them?
    >
    > Thanks,
    > jules
    >
  • OK, this does not contains as much info as you want.

    depending your need, you may activate core dump generation. So you
    will be able to launch gdb on the dump to retreive the info you need.

    http://developer.apple.com/technotes/tn2004/tn2124.html#SECCOREDUMPS

    Le 23 janv. 09 à 20:18, Jean-Daniel Dupas a écrit :

    > It already does it if debug symbols are available.
    >
    > For example:
    >
    > 3  libnspr.4.dylib                           0x00090636 PR_CreateFileMap + 0
    > (prmmap.c:52)
    > 4  libnss.3.dylib                           0x002b9601
    > PK11_GetInternalKeySlot + 74 (pk11slot.c:1659)
    > 5  org.shadowlab.MyLibrary             0x00052b5f -[KIService
    > createCertificate:] + 142 (KIService.m:46)
    > 6  org.shadowlab.MySoftware          0x00002b9d -
    > [MKIAuthorityDocument editorDidEnd:result:context:] + 193
    > (MKIAuthorityDocument.m:54)
    > 7  com.apple.AppKit                     0x964ea233 -[NSApplication
    > endSheet:returnCode:] + 288
    > 8  org.shadowlab.MySoftware          0x00007578 -
    > [WBWindowController close:] + 140 (WBWindowController.m:62)
    > 9  org.shadowlab.MySoftware          0x00004086 -[MKIRequestEditor
    > ok:] + 660 (MKIRequestEditor.m:206)
    >
    >
    > Le 23 janv. 09 à 19:45, Jules Colding a écrit :
    >
    >> Hi,
    >>
    >> Is there any way to make CrashReporter show stack frame content and
    >> line numbers instead of signatures and offsets? Maybe a way to make
    >> gdb automatically attach to crashing processes and do a "t a a bt
    >> f" on them?
    >>
    >> Thanks,
    >> jules
    >>

    >
  • On 23/01/2009, at 20.33, Jean-Daniel Dupas wrote:

    > OK, this does not contains as much info as you want.
    >
    > depending your need, you may activate core dump generation. So you
    > will be able to launch gdb on the dump to retreive the info you need.
    >
    > http://developer.apple.com/technotes/tn2004/tn2124.html#SECCOREDUMPS

    Yes, that is my thought too. Now I just have to wait for a crash ;-)

    Thanks,
      jules
  • > Yes, that is my thought too. Now I just have to wait for a crash ;-)

    And that's why my app contains this gem:

    - (IBAction) crashNow: (id) sender
    { *(char*)0=0; }

    --
    Scott Ribe
    <scott_ribe...>
    http://www.killerbytes.com/
    (303) 722-0567 voice
previous month january 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