symbolicatecrash can kiss my arse
So I just spent all this evening debugging the fixed version of symbolicatecrash, attempting to see why it wasn’t working for me. I found a few bugs, fixed them (eventually—Perl is a language I’ve not used extensively, and not at all for about 10 years). Here I’ll go through what I had to change & why.
It all boiled down to the large regular expression used to pull out the details of the binary images (the long list at the bottom of the crash log). The original version looked like this (including comments):
^\s* (\w+) \s* \- \s* (\w+) \s* (?# the range [1,2])
(\+)? (?# app has a + in front of the name [3])
(.+) (?# bundle name [4])
\s+ .+ \(.+\) \s* (?# the versions--generally "??? [???]")
\? (?# possible UUID [5])
\s* (\/.*)\s*$ (?# first fwdslash to end is path [6])
Line 1 pulls out the start - end memory address range as two variables. Line 2 matches the + character which may appear in front of the name. Line 3 matches the bundle name. Or does it?
It looks fine, when you consider everything that follows. Unfortunately, it ends up matching the entire remainder of the line, which kinda knackers things a bit, causing the all-important UUID to fail, along with returning a bundle name which doesn’t match any of the values in the thread backtraces.
How do we fix this? Well, since we’re looking at bundle names, we won’t have any spaces in there, so we replace it with the following:
([^\s]+)
That now matches any single word—anything that isn’t white space. So, all is now good with the world? Well, not quite. The next line matches the version numbers, which (as the comment mentions) usually wind up being ??? (???) rather than anything actually useful. But take a look at the crash log you just received from a 3.0 phone. That’s right, they removed it (makes sense, really). That means we want to make this bit optional (we still want to handle OS 2.0 devices). It’s easy enough, we just change this line like so to make it all optional:
(\s+ [^\s]+ \([^\s]+\) \s*)?
The braces around that mean it’ll return another result, so we shuffle everything else up one place in the following code.
Did that solve it? Well, no, of course it didn’t. There’s something else there in OS 3.0: the architecture.
**sigh**
So we add a new line optionally matching that, the same as for the bundle name? No, that won’t work with OS 2.0, because it’ll match any non-whitespace characters following the version, i.e. the UUID with its angle brackets. That won’t do at all, so we have to wrap the whole thing in more braces and put an OR-bar between them, giving us this:
( (\s+ [^\s]+ \([^\s]+\) \s*)? | ([^\s]+)? )
The first inner brackets match the 2.0 versions, the second match the 3.0 architecture. This will end up creating two new result values though (the outer brackets and the architecture clause), so everything else gets shuffled up even further. But is that it? Really? Honestly?
Actually, yes. That was nice, wasn’t it? The final snippet looks like this:
^\s* (\w+) \s* \- \s* (\w+) \s* (?# the range [1,2])
(\+)? (?# app has a + in front of the name [3])
([^\s]+) (?# bundle name [4])
((\s+ [^\s]+ \s*)?| (?# architecture[6])
(\s+ [0-9.]+ \([0-9.]+\) \s*)?) (?# the versions--generally "??? [???]"[7])
\? (?# possible UUID [8])
\s* (\/.*)\s*$ (?# first fwdslash to end is path [9])
After this, we just have to change the values being put into the $images array later, noting that the uuid is now in $8 and the path is in $9. Phew. That was annoying as hell.
Now save yourself the trouble of typing it all and copy it from here: