We are receiving lots of positive feedback about Smart Crash Reports. Thank you!
To address some of the requests, I have implemented a list of Smart Crash Reports enabled products where developers can submit their products to. So, if you're a developer, and you've added SCR support into your app, submit it.
There's a RSS Feed for recently updated products, too, so subscribe to it if you care.
Let's see the list grow! ;)
Since the last public available beta, we have added the ability to install it for all users using the SmartCrashReportsInstall.o module, and fixed some issues with multiple crash log windows being submitted at once.
I am proud to say that some software already has integrated support for Smart Crash Reports:
If you know of other software titles that supports Smart Crash Reports, please let me know in the comments. ;)
Anyway, please give the 1.0.1 GM some testing, and integrate it into your application (here's how).
Links:
- Smart Crash Reports 1.0.1 (User Installer)
- Smart Crash Reports 1.0.1 SDK
- Smart Crash Reports Homepage
Just a quick note on the new beta of Smart Crash Reports. Beta 6 is likely to become v1.0 (once we repackage it, change the version number, etc). Notable changes:
- Made sure autosubmit feature of Crash Reporter is working correctly with Smart Crash Reports ( defaults write com.apple.CrashReporter AutoSubmit YES )
- SDK: Now all SDK files are .o instead of .a, so you don't have to ranlib against it, especially if you store them in a VCS repository.
Download: http://www.unsanity.net/beta/smartcrashreports-10b6.dmg
I'd like to say special thanks to everyone who participated in the beta test, gave us your feedback, comments, and encouragement! Several "semi-big name" developers expressed interest in using SCR with their products, and we hope the list will grow once we kick out 1.0 release.
If you are a developer, consider supporting it even if you don't plan on incorporating the install API into your product, given it's pretty easy to do:
- Obtain an E-mail Ticket ID for the E-mail you wish to receive reports at by going to the following URL: http://www.unsanity.com/goto/email-ticket/.
- Add the following keys to your application Info.plist:
<key>SmartCrashReports_CompanyName</key>
<string>Your Company Name</string>
<key>SmartCrashReports_EmailTicket</key>
<string>SCR-XXXXXXXX</string>
Replace "Your Company Name" with a readable (short) company name, and "SCR-XXXXXXXX" with the Email Ticket ID you will receive in the E-mail after performing Step 1.
Once you've done these steps, if your application crashes and user has Smart Crash Reports installed, you'll magically receive a crash report in the mail. No hidden catch, no strings attached, just free love. ;)
Following the original post about Smart Crash Reports, and the release of beta 3, I am proudly presenting the new beta. The cow ate 1.0b4 (never got around to releasing it to public), so here are the release notes for both versions:
Version 1.0b5 (September 8, 2005)
- Improved detection of match specifiers registered for crashed CFM applications.
- Added a tiny URL to the bottom of the Crash Reporter window so user has a clue what is happening ("Enhanced with Smart Crash Reports").
- Added "Your personal information is not sent with this report. You will not be contacted in response to this report." back to the static text in the Crash Reporter window, and made static text resizable so all text fits nicely.
- SDK: Now it's possible to register Smart Crash Reports by simply adding a couple of keys into your application's Info.plist.
- SDK: Fixed an issue when it was not possible to write to the plist file in the /Library/Preferences from the API SDK.
- SDK: Also performs matching on the crashed process bundle ID, if no matching specifiers were found in the crashed thread.
Version 1.0b4 (September 7, 2005)
- Added a lot more safety checks to make absolutely sure Smart Crash Reports won't mess things up if CrashReporter.app changes drastically in future versions of Mac OS X.
- SDK: Added the Install library allowing developers to check for Smart Crash Reports existance and install it on user's systems from within their products (optional).
The most important points are probably the Install API so you can install SCR directly from within your application, and the ability to simply add a few keys to your application's Info.plist to make Smart Crash Reports read them in if the app crashes and do what it's instructed to. This makes the use of the registration API unnecessary for most cases (plugins such as Browser Plugins, Contextual Menu Modules, or APEs would still require the API to register).
Download here: http://www.unsanity.com/smartcrashreports
Feedback is appreciated!
Microsoft just recently changed the requirements to get the OEM discount on Microsoft Office and Microsoft Windows software products. For example, Windows XP Pro with Service Pack 2 from Newegg.com costs $229.95. Whereas the Microsoft Windows XP Pro with Service Pack 2 - OEM is only $146.95, an $83 savings. And in the past, all you had to do was purchase a cheap $5 (or less) PC part (like a microphone) to get the discount. In fact, Newegg actually adds a $5 Power Cable Splitter to your order if you order the OEM version of XP Pro and then gives you a $5 discount on the order so you don't even have to pay for the splitter.
With this licensing change, this "exploit" is no longer possible. This should make the so called "System Builders" very, very happy as there is now an incentive for people to buy/upgrade to their products to get the "discount" on Windows/Office. However, this may make end users that exploited this loophole very, very angry. And it might actually increase piracy of Windows and Office if the new price is far above the threshold people would otherwise be willing to pay for Windows. It also makes the "Windows XP Pro is just as cheap as Mac OS X" argument moot.
Furthermore, there is now a requirement that the OEM software must be pre-installed on fully assembled computer systems to get the discount. This means you cannot build a system running Linux or another operating system and get the OEM discount. So much for Linspire possibly taking advantage of this.
The updated agreement can be viewed here.
Thank you for your comments on Smart Crash Reports! Now, to announce the changes and our current plans on the matter:
I have created beta 2 (and 3) of the product. About the only change users will notice (although an important one) is that Smart Crash Reports will now send crash reports both to the developer and Apple. We think it's not a good idea to make Apple "miss" any of these crash reports, so new beta (likely to become final) fixes this. So now the crash dialog looks like this:
Other changes apply to the SDK:
- SDK: Made it possible to register narrow match specifiers after the broader ones were registered. This allows the developers to register a generic handler for all products of the company, and some custom handler for a specific product.
- SDK: Made it possible to pass NULL as inMatchString in the UnsanitySCR_RegisterMatchSpecifier to make it choose the main bundle identifier.
A few notes on the installation. The API will be forthcoming for that, so developers who want to install Smart Crash Reports from within their application, will have to add an additional .a (or .o) file to their project and call a single function UnsanitySCR_InstallIfNeeded(). No additional files or calls would be required - the SCR InputManager will be packed directly into the .a file (this is the same technology we use for APEInstall() in the Application Enhancer SDK). The API will determine whether SCR has to be installed based on its presence on the user machine and its version, and do all the magic for you. Otherwise, if you don't want to install it yourself, there will be a downloadable package at http://www.unsanity.com/smartcrashreports/ that you can point users to.
Anyway, here is a link to the new beta:
http://www.unsanity.net/beta/smartcrashreports-10b3.dmg
Thanks!
UPDATE 09/13: Beta 6 (FC) is out!
Might as well join in on the Apple bug reporting Friday fun. Since Tiger's release on April 29th, 2005, we've been receiving quite a few emails about an iSync crash. All of them blaming the crash on APE for some reason or another. This crash is not caused by APE or any APE Module. We've just received so many reports of the crash that, much like the previous Bluetooth Menu Extra bugfix (which was done on a Saturday, not a Friday), I just decided to spend some time and "fix" the darn bug. I mean, we're getting blamed for it anyways. And with that, birth was given to iSyncWorkaroundDealie (iSWAD). I use "fix" in quotes because this workaround is not ideal in any way. Apple should definitely not do anything like this to address the issue. This just prevents the crash from happening so you can use iSync without it crashing.
My first action was, of course, to reduce the bug and report it to Apple. And yes, I did make sure that APE wasn't even installed in the very first crash log I sent. However, the message returned was "remove all haxies and try again". ARG! I had already removed all haxies. I can't remove what's already been removed. So let's just say that I got a little hostile in the bug report. Then RadarWeb did it's lame thing it always does and started being weird. First it'd pretend as if the new crash log I uploaded was successfully uploaded, but it wasn't. Then when I tried to paste it inline, it failed.. but it really didn't fail. All was not lost. The comments on this bug shed light on the real problem, however.
It's actually caused because iSync uses a GCC supported feature called nested functions. When nested functions are used and a CFM library/PEF Binary (the native executable format for the PowerPC) is loaded, all hell breaks loose... basically. Something about loading the CFM runtime causes the stack to just get hosed and it seems iSync crashes the next time CFArrayApplyFunction is called. This usually happens inside of -[ISyncMainWindowController enableDevices:], although in rare circumstances it may happen inside any method call. So this is technically a bug somewhere in Mac OS X, but iSync seems to be the only one that suffers from the problem.
PEF Binaries aren't that unique on OS X. There are quite a few PEF Contextual Menu Modules, QuickTime Plugins, and Scripting Additions being used on OS X as the amount of emails we've received on the problem clearly demonstrates (to us at least). For instance, Adobe Photoshop CS and later requires a scripting addition called "Adobe Unit Types" to function. So if you have Adobe Photoshop CS or later and iSync 2.0 or later the following script will crash (even if you never use iSync):
tell application "iSync"
set blah to current date
synchronize
end tell
Alternatively, iSync will also crash if you have any PEF CMM modules. To test this, open the about box of iSync and right click some text. This loads all the Contextual Menu Modules. If one of the loaded CMMs is a PEF Binary, clicking the Sync button in iSync will cause a crash. Again, you don't have to actually have ever synced any devices to get this crash.
If you want to "prevent" the crash without actually installing APE, you can as long as you don't require the use of Adobe Photoshop CS. Just open the ~/Library/Logs/CrashReporter/iSync.crash.log and search the log for "PEF Binary". Ignore all the lines that start with CFMPriv_ as these are PEF Binaries included with OS X and are loaded to handle the CFM calls. Once you find the name of a PEF Binary, look in Library/Contextual Menu Items/, Library/QuickTime/, and Library/ScriptingAdditions/. The missing slash (/) at the beginning denotes it can be in any Library folder (excluding the /Sytem/Library/ folder, do not touch that one) such as the one at the root of the hard drive, or the one in your user folder. After you remove a specific PEF Binary from the hierarchy, rerun the iSync test and see if it continues to crash, if it does, start from the beginning of this paragraph again.
My first attempt (the source code to it) involved trying to re-implement CFArrayApplyFunction by copying and pasting a lot of the CFArray source code and then trying to find out where it crashed. Luckily, it did not work. It'd stop crashing inside enableDevices: and would then crash in some other random place. So that 8+ hours of trying that approach was a dead end. I wouldn't say it was a waste of time as it taught me to hate the CF code a lot more. Not that I didn't loathe it already.
Then I decided on trying to prevent any CFM Libraries from loading. And that's what actually worked. You can download the "fix" here. It will only load into iSync and won't touch any other processes. The linked disk image contains the source code and the compiled APE module. You'll need to download Application Enhancer to use the APE module (install it in ~/Library/Application Enhancers/) and if you want to compile the project you'll need Xcode 2.1 or later and the APE SDK.
Download iSyncWorkaroundDealie.dmg (72k)
If you're a Mac developer, have you ever wanted CrashReporter.app to work for your applications so you can receive these crash logs and act appropriately, fixing the bug in question in a timely manner? So have we. And I think we now have something to show you that may fulfill that exact wish...
Say hello to Smart Crash Reports! This is a project we're been working on over past few days, and I think it has some potential. Now, what exactly are Smart Crash Reports?
Smart Crash Reports is an enhancement for the Apple's CrashReporter application introduced in Mac OS X 10.4. It allows 3rd party developers to enhance CrashReporter in a way that if it determines that the crash is likely attributed to the 3rd party application, the crash log will be sent to the developer as well as Apple. This enhances the user experience of the OS, and allows developers to receive crashes and improve their software in a timely manner.
Smart Crash Reports requires no Application Enhancer or similar "patching" frameworks users have to install; they operate on the InputManager mechanism that is built-in Mac OS X. Which means, only Smart Crash Reports has to be installed, and it does not require Administrator privileges.
Smart Crash Reports is completely free to use for both users and developers; The plan is Unsanity will be providing it as a service to the community.
Now, what does this means to the casual user? Let's pretend some application crashes on them:
User clicks Report..., and Smart Crash Reports kicks in, analyzes the crashed thread and notices that "com.unsanity." is in it, which means the crash is related to us (we have previously registered ourselves with the Smart Crash Reports to tell it about it). So the user gets this:
Smart Crash Reports gives user the opportunity to send you, the developer, the crash log, so you can look at it, take some action, and possibly fix a bug in your product! Note that if Smart Crash Reports cannot find the "source" of the problem, Crash Reporter window looks and acts exactly like before ("Send to Apple...", etc).
Now how would a developer receive these crash logs? We've created two ways to do it for you: either you get them sent to the e-mail you provide, or you implement your own Web CGI script that processes the reports right on your server. It's up to you.
Why do I post it here? I'd like you, the developers, to try it out. I'd also like you, our users, to try it out as well - tell us what you think, what are we doing wrong, do you like it or not, and everything like that. Help us out by letting us know how to improve it and what you think of the idea before it hits 1.0.
Now, the pointers!
- Developer Documentation (how to use and adopt Smart Crash Reports for your products)
Smart Crash Reports 1.0b3.dmg- The installer of beta of Smart Crash Reports (~350K) (see this post for the latest beta)
- Sample BombApp.app, that will crash and trigger Smart Crash Reports (BombApp has com.unsanity. identifier, so it will be treated as an Unsanity crash log when it crashes).
Please give us your feedback!
UPDATE 09/13: Beta 6 (FC) is out!