//
you're reading...

Programming

Choosing a crash reporting system for Cocoa

Bad day at the officeToday I’ve installed FeedbackReporter in my upcoming Mac OS X app and Mantis Bug Tracker in Basil Salad’s hosting account to manage the possible incoming crash reports sent by the app. Although FeedbackReporter has a Mantis connector bundled, it wasn’t a “just works” integration process. FeedbackReporter’s bundled provided connector’s local API option tries to call a function in Mantis that doesn’t exist so I was forced to use the SOAP API option instead. After that was sorted out it turns out that FeedbackReporter requires a “Feedback” category to be setup in Mantis and I found this out the hard way by debugging the connector’s PHP code – which includes deliberately crashing my app (simple enough, just write something to a NULL pointer) and trying to send a crash report. Not to mention I had to troubleshoot sendmail issues in the web hosting account (but that’s out of topic right now).

The reason behind all this work is that that I’m preparing the Mac App to be beta-quality and having a crash reporter is essential since I can’t ask the beta testers to collect log files and send them to me. Furthermore I don’t have the luxury of a “first-level support team” that can login to the customer’s PC, take screenshots and log files. My definition of “beta quality” is simply “can run reliably without needing to be attached to a debugger and can run by someone else without my supervision”. The application’s name is a secret for now, I just call it “Mac App” since it’s going to be my first “real” application for the Mac.

How did I came to the decision to use Feedback Reporter? Initially I googled a bit along the lines of “cocoa crash reporter” and then found a Stack Overflow post that points me to Daniel Jalkut’s list of Mac OS X crash reporters.

I looked at Daniel’s list and initially interested with Unsanity’s Smart Crash Reports. Then again their crash reporter requires me to install their component system-wide in the customers’ machine, which not something I want to do for my simple application.

Then I got interested in ILCrashReporter-NG since it promises to send the crash reports via e-mail. Receiving crash reports via e-mail means that I don’t have to spend the effort to setup a server-side application to receive those reports. I’ve tried the demo and it turns out that my crash reports were being rejected by Google’s mail servers (I used Google Apps for e-mail) and the reason is that my IP address was suspected as a spam source. At the time my computer was connected through a consumer broadband internet link which changes my external IP address every few seconds. Looks like my ISP’s IP addresses are suspected by Google as a spam source. If my (future) users or beta testers suffers from the same issue, sending crash reports via e-mail is going to be a problem.

Similarly HDCrashReporter can make use of the user’s e-mail account to send crash reports via e-mail. At first I thought that this may be a good idea but I then I decided not to go with it. Reason being is that a lot of “non-techie” users prefer web-based GMail or Yahoo and won’t bother to setup the Mail application (or even Entourage or Firebird for that matter). Thus Apple’s NSMailDelivery class may not be able to send any e-mail in the first place and thus my crash reports cannot be sent. Furthermore HDCrashReporter is LGPL and some prominent Mac indie developers (I can’t remember exactly who but I think he’s one of Scotty’s friends) steer clear out of LGPL even though that there is an “L” in front of the GPL, since he doesn’t want to be a legal test case. Since I’m relatively new and “green” in this Mac indie thing, I think it will be good to heed the old-timers opinions.

Breakpad was interesting too since it is actively used by Mozilla. The problem is that the server-side component (the part that receives the crash reports) seems to be a native C++ based application — which could be a problem to get it to compile and run under a shared web hosting environment. So Breakpad was also scratched.

So I ended up with FeedbackReporter. It’s simple enough to integrate and already have a supported “back-end” interface (Mantis Bug Tracker) that is written in PHP. The back-end practically have to be PHP since it’s the only scripting language (apart from the Linux shells) that is supported by my shared web hosting provider. I’ve read that adding support for Unsanity’s Smart Crash Reports isn’t too difficult (just register with their website and add a few entries in the Info.plist file). I’ll probably add support for it in case the end-user already have it installed but I don’t think I’ll force users to install it. I do agree with Daniel that Apple should share their crash reports to the developers.

PS: Apparently the Mantis Connector of FeedbackReporter needs some more work. Out of the box it garbles all the attached files in the report. Apparently Mantis’ SOAP API requires attachments to be base64 encoded.

If you use FeedbackReporter with Mantis, you’ll need to change the mantis.php file in the connector and update these lines:

        $this->client->mc_issue_attachment_add( MANTIS_USER, MANTIS_PWD, $bugID,
                $name, ‘text/plain’, $str );

so that it reads like this:

        $this->client->mc_issue_attachment_add( MANTIS_USER, MANTIS_PWD, $bugID,
                $name, ‘text/plain’, base64_encode($str) );

Thanks and good luck.



Do you enjoy this post? Enter your e-mail address below to receive articles like this one in your mailbox.
  • Torsten

    Thanks for using FeedbackReporter. The Mantis is contrib level software and I am not using it myself. But would you mind providing a patch to make this easier for others?

    Thanks for the write-up.

Free Updates!

Learn how to grow your indie business while keeping your day job.

Categories

Archives

Keep updated!

Don't miss out on new articles!
%d bloggers like this: