Crash Reporter for Cocoa Application

  • Hi All,
              I've developed a Cocoa Application which uses networking
    utilities.

              Now i've an idea to integrate a Crash Reporting Facility into My
    application which enables our customers to report us if it crashes.

              Is there any way to customize Apple Crash Report to send crash
    logs to our server.

            Can any one provide suggestions on usage of 3rd party
    frameworks/libraries and their pros & cons.

            Thanks in Advance.

    -JanakiRam.
  • There's no way to tell Apple's crash reporter to send reports to you.
    You can write your own crash reporter app or find open-source ones.

    Perhaps the easiest thing to do, though, is to look in the ~/Library/
    CrashReporter/YourApp folder when the app starts up, and see if any
    new files are there. If so, the user crashed in their previous run,
    and you can offer to send in the report. Voila, a crash reporter in a
    very small amount of code (and it's not fiddly like catching signals
    or dealing with Mach exceptions can be).

    On Nov 11, 2007, at 9:33 AM, JanakiRam wrote:

    > Hi All,
    > I've developed a Cocoa Application which uses networking
    > utilities.
    >
    > Now i've an idea to integrate a Crash Reporting Facility
    > into My
    > application which enables our customers to report us if it crashes.
    >
    > Is there any way to customize Apple Crash Report to send
    > crash
    > logs to our server.
    >
    > Can any one provide suggestions on usage of 3rd party
    > frameworks/libraries and their pros & cons.
    >
    > Thanks in Advance.
    >
    > -JanakiRam.
  • On 12 Nov 2007, at 01:15, John Stiles wrote:

    > There's no way to tell Apple's crash reporter to send reports to
    > you. You can write your own crash reporter app or find open-source
    > ones.
    >
    > Perhaps the easiest thing to do, though, is to look in the ~/Library/
    > CrashReporter/YourApp folder when the app starts up, and see if any
    > new files are there. If so, the user crashed in their previous run,
    > and you can offer to send in the report. Voila, a crash reporter in
    > a very small amount of code (and it's not fiddly like catching
    > signals or dealing with Mach exceptions can be).

    About 18 months Uli Kusterer and I both posted code for handling crash
    reports.  The two methods employed each have their own benefits and
    drawbacks.  You can find the posts here:
    http://lists.apple.com/archives/Cocoa-dev/2006/Feb/msg00360.html
    http://lists.apple.com/archives/Cocoa-dev/2006/Feb/msg00586.html

    Having said that, this seems like something so many people want to do
    that perhaps Apple should consider adding some code to their Crash
    Reporter which looks in the Info.plist of the crashed application for
    a URL to which to post crash information and give the user an easy way
    to report crashed in 3rd party apps.  I think I shall file an
    enhancement request to this effect.

    Cheers,
      Nicko
  • My application's crash reporting tool is an application located in the
    Resources folder. The application is linked against a small framework.
    It basically connects to a WebService and uploads the following:
    Application Name, Application Version, OS Version, RAM Size, etc...
    Users can turn on and off crash reports or chose not to broadcast the
    personal machine data to the internet. These are then stored on my
    server and reviewed.

    I would take a look at Adium's Crash Reporting utility. That is where
    I got my ideas...

    On Nov 11, 2007, at 11:33 AM, JanakiRam wrote:

    > Hi All,
    > I've developed a Cocoa Application which uses networking
    > utilities.
    >
    > Now i've an idea to integrate a Crash Reporting Facility
    > into My
    > application which enables our customers to report us if it crashes.
    >
    > Is there any way to customize Apple Crash Report to send
    > crash
    > logs to our server.
    >
    > Can any one provide suggestions on usage of 3rd party
    > frameworks/libraries and their pros & cons.
    >
    > Thanks in Advance.
    >
    > -JanakiRam.
  • As long as people can't interrupt crash reports being sent to Apple,
    I'd like to have an official way to get crash reports from users, too.

    Suppose I should file a request as well. :-)

    --
    m-s

    On 11 Nov, 2007, at 20:35, Nicko van Someren wrote:

    > Having said that, this seems like something so many people want to
    > do that perhaps Apple should consider adding some code to their
    > Crash Reporter which looks in the Info.plist of the crashed
    > application for a URL to which to post crash information and give
    > the user an easy way to report crashed in 3rd party apps.  I think I
    > shall file an enhancement request to this effect.
  • Another way to do it is to have a helper application polling to check for a
    new crash report, and send it as soon as it happens. The trick is to get
    that helper application running, because if you just launch it from your
    main application, then it is a child of your main application, so as soon as
    your main application crashes the child is terminated. The trick to making
    it work is to have your main application use launchctl to launch the helper.

    Sneaky, but it works. For most apps it may be overkill. But for a custom
    application where you want to provide a very high level of support, it's
    great. An app crashes, I get page within a minute. Even more so, my helper
    app monitors my app's own log looking for reports of internal error
    conditions.

    --
    Scott Ribe
    <scott_ribe...>
    http://www.killerbytes.com/
    (303) 722-0567 voice
  • 12 nov 2007 kl. 03.35 skrev Michael Watson:

    > As long as people can't interrupt crash reports being sent to Apple,
    > I'd like to have an official way to get crash reports from users, too.
    >
    > Suppose I should file a request as well. :-)

    I filed an enhanchment bug on this at Apple Radar at  20-Nov-2003, was
    stated as duplicate.

    BugID:3491610
    Orignal BugID:356232

    // Totte
    >
    >
    >
    > --
    > m-s
    >
    >
    > On 11 Nov, 2007, at 20:35, Nicko van Someren wrote:
    >
    >> Having said that, this seems like something so many people want to
    >> do that perhaps Apple should consider adding some code to their
    >> Crash Reporter which looks in the Info.plist of the crashed
    >> application for a URL to which to post crash information and give
    >> the user an easy way to report crashed in 3rd party apps.  I think
    >> I shall file an enhancement request to this effect.


    --------------------------------------------------------------------------------------------------
    !YET the successor of .NET
  • On 12 Nov 2007, at 06:20, Totte Alm wrote:

    > I filed an enhanchment bug on this at Apple Radar at  20-Nov-2003,
    > was stated as duplicate.
    >
    > BugID:3491610
    > Orignal BugID:356232

    Wow, that's an old Bug number.

    There's also unsanity's SmartCrashReports <http://
    smartcrashreports.com/>.

    It's an inputManager if I recall correctly, which means it installs
    system wide (but needs application support), and won't run on 64-bit
    systems by my understanding. I believe that you can bundle the
    installer into your app, and then ask permission to install it if it
    isn't already.

    It's what Adium, Textmate, Quicksilver & Opera (amongst others) use,
    so it's already on a lot of machines.
  • There's no trick here. Just use Launch Services or NSWorkspace -
    openFile: to launch the helper app, and it will be a child of the
    window server. This has always been the right way to launch GUI app.
    Fork/exec leave the app as a child of your app, causing lots of minor
    issues.

    On Nov 11, 2007, at 9:07 PM, Scott Ribe wrote:

    > Another way to do it is to have a helper application polling to
    > check for a
    > new crash report, and send it as soon as it happens. The trick is
    > to get
    > that helper application running, because if you just launch it from
    > your
    > main application, then it is a child of your main application, so
    > as soon as
    > your main application crashes the child is terminated. The trick to
    > making
    > it work is to have your main application use launchctl to launch
    > the helper.
    >
    > Sneaky, but it works. For most apps it may be overkill. But for a
    > custom
    > application where you want to provide a very high level of support,
    > it's
    > great. An app crashes, I get page within a minute. Even more so, my
    > helper
    > app monitors my app's own log looking for reports of internal error
    > conditions.
    >
    >
    > --
    > Scott Ribe
    > <scott_ribe...>
    > http://www.killerbytes.com/
    > (303) 722-0567 voice
  • > There's no trick here. Just use Launch Services or NSWorkspace -
    > openFile: to launch the helper app, and it will be a child of the
    > window server. This has always been the right way to launch GUI app.
    > Fork/exec leave the app as a child of your app, causing lots of minor
    > issues.

    I didn't know Launch Services would do that. I suppose it should have been
    obvious, but...

    Anyway, I used NSTask. Until (around 10.4.10) it stopped working with a
    mysterious error message on some Macs but not others. I switched to
    vfork/exec. But I only to launch a script which calls launchctl and then
    returns--so there is no process left as a child of my app.

    I'll look at the other options next time I update anything about this.

    --
    Scott Ribe
    <scott_ribe...>
    http://www.killerbytes.com/
    (303) 722-0567 voice
  • Yeah, you are going the long way around here. NSWorkspace -openFile:
    is a one liner and will get rid of a lot of extra hassle for you.

    On Nov 12, 2007, at 10:03 AM, Scott Ribe wrote:

    >> There's no trick here. Just use Launch Services or NSWorkspace -
    >> openFile: to launch the helper app, and it will be a child of the
    >> window server. This has always been the right way to launch GUI app.
    >> Fork/exec leave the app as a child of your app, causing lots of minor
    >> issues.
    >
    > I didn't know Launch Services would do that. I suppose it should
    > have been
    > obvious, but...
    >
    > Anyway, I used NSTask. Until (around 10.4.10) it stopped working
    > with a
    > mysterious error message on some Macs but not others. I switched to
    > vfork/exec. But I only to launch a script which calls launchctl and
    > then
    > returns--so there is no process left as a child of my app.
    >
    > I'll look at the other options next time I update anything about this.
    >
    > --
    > Scott Ribe
    > <scott_ribe...>
    > http://www.killerbytes.com/
    > (303) 722-0567 voice
    >
    >
  • On Nov 12, 2007, at 4:34 AM, Paul Sargent wrote:

    > There's also unsanity's SmartCrashReports

    Which is an unsupported hack.  See:

    http://www.friday.com/bbum/2006/01/20/sandvox-hidden-feature/

    for why this is a very bad idea.

    -jcr

    John C. Randolph,
    VP, Engineering
    Stealth Imaging, LLC. <jcr...>
  • On Nov 13, 2007 12:44 AM, John C. Randolph <jcr...> wrote:

    >
    > On Nov 12, 2007, at 4:34 AM, Paul Sargent wrote:
    >
    >> There's also unsanity's SmartCrashReports
    >
    > Which is an unsupported hack.  See:
    >
    > http://www.friday.com/bbum/2006/01/20/sandvox-hidden-feature/
    >
    > Which is exactly why I stated it was an inputManager up front. Maybe the
    consequences of that fact are not widely known.

    I'm not a fan either, but it is what a lot of apps use, some of which were
    mentioned in the thread.
  • On 13.11.2007, at 01:44, John C. Randolph wrote:

    > Which is an unsupported hack.  See:
    >
    > http://www.friday.com/bbum/2006/01/20/sandvox-hidden-feature/
    >
    > for why this is a very bad idea.

    Which - in turn with the combination with Leopard upgrade problems due
    to input managers - might be an indication that it is a very bad idea
    from Apple to ignore constant and obvious requests from 3rd party
    developers.

    Sending back crashreports is implemented ubiquitous with more or less
    unsupported methods and requested pretty often. Providing a 3rd party
    crashreport "CC:"  address in combination with code-signing might have
    made that feature far more attractive for developers and not just an
    extra hassle.

    Regards,
    Tom_E
  • On 12 Nov 2007, at 05:07, Scott Ribe wrote:

    > Another way to do it is to have a helper application polling to
    > check for a
    > new crash report, and send it as soon as it happens. The trick is to
    > get
    > that helper application running, because if you just launch it from
    > your
    > main application, then it is a child of your main application, so as
    > soon as
    > your main application crashes the child is terminated. The trick to
    > making
    > it work is to have your main application use launchctl to launch the
    > helper.

    Polling the crash report file is both wasteful and unnecessary when
    you have kernel events, and launchd already provides a mechanism for
    firing off a program when a file changes.  See my posting on this same
    subject from a year and a half ago:
    http://lists.apple.com/archives/Cocoa-dev/2006/Feb/msg00586.html

    Nicko
  • > Polling the crash report file is both wasteful and unnecessary when
    > you have kernel events, and launchd already provides a mechanism for
    > firing off a program when a file changes.

    Yes, I'm aware of that--it's why I haven't posted the code publicly and
    announced "look everybody, a non-intrusive way to get crash reports". The
    current thing is more prototype quality, implemented in Ruby, and has
    another problem in addition to the polling: possibility of a race condition
    on rapid app re-launch causing the crash log monitoring to not run.

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