Comments on: SCR: Response from Sandvox

By: RJVB

RJVB — Tue, 31 Jan 2006 18:35:38 +0000

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?!

By: Bob K

Bob K — Wed, 25 Jan 2006 12:39:54 +0000

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.

By: Bob K

Bob K — Tue, 24 Jan 2006 15:54:11 +0000

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.

By: Not Required

Not Required — Mon, 23 Jan 2006 04:43:43 +0000

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.

By: David

David — Sun, 22 Jan 2006 22:12:59 +0000

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!

By: Not Required

Not Required — Sun, 22 Jan 2006 03:33:33 +0000

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.

By: Rosyna

Rosyna — Sun, 22 Jan 2006 02:11:05 +0000

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.

By: Not Required

Not Required — Sat, 21 Jan 2006 23:45:10 +0000

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.

By: Rosyna

Rosyna — Fri, 20 Jan 2006 21:41:35 +0000

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)