SCR: Response from Sandvox

I received the following from Terrence Talbot, one of the Sandvox developers:

b.bum: Sorry to catch you off-guard. In the next public version of Sandvox we’ll include an extra dialog specifically allowing the user to install — or not — SmartCrashReports.

A number of great apps out there make use of SCR. I don’t mean to draw other developers into the controversy, but Unsanity publishes a list on their site. FlickrExport, for example, links to the same .o as we do, but doesn’t install SCR. If it’s there, fine, it uses it. If not, no crash reports go back to the developer. This is a fairly important feature for us, however, particularly during the beta period. You’re right though, we should have made its use explicitly optional.

Putting the merits of using an InputManager aside just for a moment, SCR is actually a very nice solution in terms of “on the screen” user experience. Apps crash, and reports go out, in the “standard” way (over HTTP).

The only other “public” crash reporter for developers is ILCrashReporter which we’ve also tried. It, too, is somewhat of a hack, killing off Apple’s CrashReporter and leaving a third process running around that didn’t always go away. (It also explicitly uses SMTP which our early beta testers found to be blocked by corporate firewalls.)

An in-house solution would probably need to be a similar hack since some process would have to run outside the app watching for problems — just as Apple’s crashreporterd does now. Would you consider this to be unacceptable? (I think having extra processes running around, not under control of the system, has its own set of problems for the user.)

Obviously as a user you shouldn’t have to care. As a fellow developer, however, I’d rather use this as an opportunity to push for a crash reporter that we all can use. SCR seemed to be a great step in that direction. What’s the best way to move this forward for everyone?

I would like to see the same kind of tool, as well. I agree that having an additional daemon or that replacing Apple’s crash reporter isn’t really a good solution. Fortunately, it doesn’t appear to be necessary.

One person suggested something that monitors ~/Library/Logs/CrashReporter and redirects bugs accordingly. This is certainly a viable solution. It could be done via launchd, which can easily monitor a path or directory for activity.

Another solution is to do this entirely from within your own process. That was how CrashCatcher worked. Or do so in a wrapper application that springboard launches the real application. Sandvox is actually already doing this to provide the user with a nice dialog indicating that Sandvox won’t work on versions of Mac OS X prior to Tiger.



10 Responses to “SCR: Response from Sandvox”

  1. Rosyna says:

    The problem with all of those solutions is that they double the UI for crash reports (or worse, never send the crash reports to Apple). As the FAQ says, the latter is not good for users in the long run. Also, they tend to either make the developer code a lot or require them to link to third party code (with SCR, it is completely optional for third party developers to link to or install SCR, all that is “really” required is two Info.plist keys)

  2. Not Required says:


    The problem with all of those solutions is that they double the UI for crash reports (or worse, never send the crash reports to Apple).

    Firstly, I would say that not bothering Apple for third-party application bugs is better, not worse, but they’re the ones that decided to make the window come up for every application. Yes, you double the UI, but for something like a crash that is supposed to be so rare, it is hardly a show-stopper problem.


    Also, they tend to either make the developer code a lot or require them to link to third party code

    Simply not true. It would be trivial to create a no-fuss framework (or bundle) that checked for log changes when an application starts and presents the user with a dialog to notify the developer. Bill and everyone else who points to non-invasive solutions is so very right that it makes developers who can’t see it look all manner of foolish.

  3. Rosyna says:

    How is that not true? Including a framework would require they link to and load third party code. There is no difference here. SCR *is* a bundle. But Application developers don’t have to modify a line of code or link to anything to support it.

  4. Not Required says:

    It’s not true by nature of the degree implied by your statement. The first part of your claim is that it requires a lot of code to put up a dialog and ship off a log file; it could probably be done in 10 lines and done well in 100 (witness the CrashReporter executable itself is a mere 48k). The second claim is that it requires some kind of linking, but whatever it takes is under the developer’s control and will certainly be less globally invasive than SCR is. That is, since the operation of reporting is independent of regular application function, the framework need not require special coding for support by the application; just add it in Xcode and you’re done. Even if it were a good idea for support at the system level, it is baffling that you’ll defend using the haxie method for the modification of just CrashReporter when what should have been implemented is a solution that affects just that application. Even if that meant swapping out Apple’s app for a third-party substitute, at least it couldn’t be done behind the user’s back and at least it wouldn’t change the behavior of every running app.

  5. David says:

    witness the CrashReporter executable itself is a mere 48k
    48k of code is a LOT of code. Granted some of that is just support and linkage, but it really isn’t a small amount of work. Secondly, SCR isn’t globally invasive, it only does it work in the Crash Reporter process. All other processes have nothing done to them. Next, you can’t just add a framework to an application and have it do something. Frameworks aren’t initialized until you USE them, so if you never use the framework, then nothing happens. Next, SCR doesn’t use the Haxie method (APE), it uses an InputManager – same as a lot of other code that runs on your system. Finally, not sending the crash report to Apple is a bad thing, because the buy might actually be one of Apple’s!

  6. Not Required says:

    Wow, you’ve managed to make a post where every point is provably wrong.


    48k of code is a LOT of code. Granted some of that is just support and linkage, but it really isn’t a small amount of work.

    A brand new Xcode application project out of the box builds to . . . wait for it . . . 48k! To be byte-specific, 46868 compared to CrashReporter’s 46928. If you think 60 compiled bytes amounts to “a LOT” of code, remind me to never hire you to develop anything ever.


    Secondly, SCR isn’t globally invasive, it only does it work in the Crash Reporter process. All other processes have nothing done to them.

    Code is loaded and code is executed by every app. That more of the code is executed by CrashReporter is not the issue.


    Next, you can’t just add a framework to an application and have it do something. Frameworks aren’t initialized until you USE them, so if you never use the framework, then nothing happens.

    Either you’re not a developer or you’re just not a very good one. Look into the +load method for starters.


    Next, SCR doesn’t use the Haxie method (APE), it uses an InputManager – same as a lot of other code that runs on your system.

    NO other code on my system is hacking the input manager mechanism. That those particulars of SCR code insertion differ from APE is again not the issue. The issue is that code gets loaded by every app; it is globally invasive when the intent is to modify just CrashReporter. A haxie is a haxie is a haxie.


    Finally, not sending the crash report to Apple is a bad thing, because the buy might actually be one of Apple’s!

    Trust me, it’s not. The odds are overwhelming that the bugs are in your code. Under the unlikely circumstance your app is triggering a bug in Apple’s code, you as a developer should file a proper bug report. It is totally unhelpful to flood Apple with crash reports from non-Apple apps. Everything about SCR is poorly thought out, and people are right to take issue with Sandvox for quietly installing it.

  7. Bob K says:

    How do we get rid of the crash reporter? I trashed it from the input manager folder then restarted and emptied the trash. Also removed Sandvox and everything related I could find with sandvox in the name. Is there something else? Also, this could be a huge coincidence, but my system Help Viewer no longer works. It crashes on startup and it does not send a report to Apple. These are are probably two separate issues, but they could be the same. I am a beta tester, not a developer, so I’m used to nutty stuff — but not thoughtless stuff — and I don’t freak out over having to rebuild my system, which I’m probably going to have to do. But I am curious if I have the entire crash reporter and it’s footprints are removed. Thanks.

  8. Bob K says:

    In fairness to the Sandvox folks, the Help Viewer problem appears to have been something else and is now fixed. Also followed the link at the top of the page to make sure Smart Crash Reporter is gone and no Input Managers can be installed. Thanks.

  9. RJVB says:

    Why this perceived need to write something new? A Quality Feedback Agent already exists and is used by Mozilla.org . It works like the Crash Reporter, but can delay the sending of reports (just to name a difference).
    Surely other vendors could use this, or related technology?!

  10. Jane Savoie says:

    The Debug menu is a special menu that can be enabled in Sandvox to provide some advanced troubleshooting commands. (The Debug menu is in English only, regardless of the language that Sandvox is using

    To enable the Debug menu:

    1. Quit Sandvox.
    2. Open the Terminal (found in the “Applications → Utilities” folder).
    3. Type the command:

    defaults write com.karelia.Sandvox IncludeDebugMenu -bool YES

    4. Press Return.
    5. Launch Sandvox.

    To disable the debug menu:

    1. Repeat the above instructions, but instead enter the command:

    defaults write com.karelia.Sandvox IncludeDebugMenu -bool NO

    Learn more at: http://docs.karelia.com/z/Debug_Menu.html

Leave a Reply

Line and paragraph breaks automatic.
XHTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>