When any program crashes, it produces a crash report, which contains some information about your computer, most notably what it was doing when it crashed. If you look at the crash report, you'll see the type of error that caused the crash, and a list of threads followed by a numbered list of arcane commands, called a stack trace. One of these threads will say "Crashed," and its stack trace, together with the error name, could be considered your crash's signature.
Every crash has a signature, and the same crash on different computers will have basically the same signature. Theoretically, if you knew what to look for, you could get all CSI on your computer and know why it was crashing and maybe even fix it.
While crashes in Delicious Library are, honestly, quite rare, if you do crash, chances are you'll crash while loading something from Amazon, and that crash will have a signature very similar to this:
0 com.apple.CoreFoundation 0x907c7cf8 CFHash + 24
1 com.apple.CoreFoundation 0x907d4088 __CFSetFindBuckets2 + 148
2 com.apple.CoreFoundation 0x907d3bf8 CFSetAddValue + 220
3 com.apple.CoreFoundation 0x9081560c _inputStreamScanXMLName + 872
4 com.apple.CoreFoundation 0x90816230 parseTag + 52
5 com.apple.CoreFoundation 0x90816ca0 parseTagContent + 388
6 com.apple.CoreFoundation 0x908163f8 parseTag + 508
7 com.apple.CoreFoundation 0x90816ca0 parseTagContent + 388
8 com.apple.CoreFoundation 0x908163f8 parseTag + 508
9 com.apple.CoreFoundation 0x90816ca0 parseTagContent + 388
10 com.apple.CoreFoundation 0x908163f8 parseTag + 508
11 com.apple.CoreFoundation 0x90816ca0 parseTagContent + 388
12 com.apple.CoreFoundation 0x908163f8 parseTag + 508
13 com.apple.CoreFoundation 0x90814d04 parseXML + 300
14 com.apple.CoreFoundation 0x90814680 CFXMLParserParse + 444
15 com.apple.CoreFoundation 0x908500b8 CFXMLTreeCreateFromDataWithError + 100
16 com.delicious-monster.library 0x0008ce80 0x1000 + 573056
17 com.delicious-monster.library 0x0009871c 0x1000 + 620316
18 com.delicious-monster.library 0x0009319c 0x1000 + 598428
19 com.delicious-monster.library 0x00092e70 0x1000 + 597616
20 com.delicious-monster.library 0x000920cc 0x1000 + 594124
21 com.delicious-monster.library 0x0009988c 0x1000 + 624780
22 com.apple.Foundation 0x92932194 forkThreadForFunction + 108
23 libSystem.B.dylib 0x9002ba68 _pthread_body + 96
What does all that mean? Long story short, this is a bug in Apple's CoreFoundation XML parser, which Delicious Library uses to convert the raw data from Amazon into the items on your virtual shelves. Unfortunately, as this is in an Apple class, we can't really fix this, which is why it remains our most common crash.
The best option would be for us to use a different XML parser, but that means literally re-architecting our Amazon lookup engine. (This is not the sort of thing that happens in a point release, but is the sort of thing that will happen in Delicious Library 2.)
Some crashes are easier to fix, once we can track them down. If you're using an older version of Delicious Library, your most common crash is one that doesn't usually have any stack traces associated with it. Rather, the crash report is an almost completely blank page with the title "Exception thrown: NSArchiverArchiveInconsistency."
This crasher also had a non-crashing behavior, where something that was obviously on Amazon would nonetheless fail on lookup. Wil wrote
a whole blog entry about this bug when we found it, which you can read for historical or educational purposes, but for now, if you're getting this, your best bet is to upgrade to the latest version of Delicious Library.
Other than the XML parser, crashers are so rare it's literally a three-way tie for second place.
The first has a signature that starts with this:
0 com.ioxperts.vdig.webcam.Logi 0x16cd9ab8 dyld_stub_exp + 381436064
1 com.ioxperts.vdig.webcam.Logi 0x16cd99d8 dyld_stub_exp + 381435840
2 com.ioxperts.vdig.webcam.Logi 0x16cd56fc dyld_stub_exp + 381418724
3 com.ioxperts.vdig.webcam.Logi 0x16cdb104 dyld_stub_exp + 381441772
4 com.ioxperts.vdig.webcam.Logi 0x16cf546c dyld_stub_exp + 381549140
5 com.ioxperts.vdig.webcam.Logi 0x16cd5dc0 dyld_stub_exp + 381420456
6 com.ioxperts.vdig.webcam.Logi 0x16ce6ea8 dyld_stub_exp + 381490320
7 com.ioxperts.vdig.webcam.Logi 0x16ce7c30 dyld_stub_exp + 381493784
8 com.ioxperts.vdig.webcam.Logi 0x16ce78e0 dyld_stub_exp + 381492936
9 com.ioxperts.vdig.webcam.Logi 0x16cffc50 VideoDigitizerEntry + 68
This is a crash in a third-party USB web cam driver by a company called IOExperts. If you're using this driver, you're prone to this crash.
The second starts with a statement like this:
NSInvalidUnarchiveOperationException - *** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (BXLayout)
This happens when you are trying to import a Booxter library. We don't know what a BXLayout is, so we don't know why some Booxter libraries crash like this, and the way Booxter stores its data is such that we can't do anything about this on our end. If you're getting this crash and you figure out what in your Booxter library you can change to make it not crash on import, we'd like to know. Otherwise, your best bet is to export your Booxter library into a tab-delimited text file and import that into Delicious Library.
The third is really more like a crash cluster. There are a bunch of different signatures, but they all point to the same thing: the video channel. You don't even need to read crash reports to know that if you're using a video capture device, be it an EyeTV plugged in your USB port or a full-blown Kona video capture card, this will conflict with Delicious Library and crash.
After those three, the remaining crashers are basically random, but that speaks to the importance of sending those crash reports along. While we don't usually respond to them, we do read and file every single one of them. After time, patterns form, investigations are launched, bugs are found and hopefully fixed.
Then, there's a second, entirely different, class of crasher. That is, a crasher you get all the time, but nobody else gets. If you're crashing a lot, that's probably what it is. We can help you with those, but we need some information from you. Namely, we need you to mess with it enough to figure out what you do to make it crash. Ideally, you should be able to crash it at will. Then, send us three things.
1) A detailed narrative of what you do to make it crash. The key word here is detailed. Sometimes what you think is happening is only peripheral to what's really happening, so knowing everything really helps.
2) Any Delicious Library crash logs. You can find these in your home folder under ~/Library/Logs/CrashReporter/
3) The most recent console log. This is found in the main folder under /Library/Logs/Console/501/ and should be named console.log.
Any crasher is frustrating, but with knowledge, science, and luck most crashers can be tracked down and sent to that big bug report in the sky.
Mike Lee, Major-domo
Delicious Monster Software, LLC
Top