Closed Bug 514124 Opened 15 years ago Closed 13 years ago

Make libobjc.A.dylib@0x1568c the first part of a "compound signature"

Categories

(Socorro :: General, task)

Product:
Socorro
Component:
General
Platform:
All
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: alqahira, Unassigned)

Details

+++ This bug was initially created as a clone of Bug #496474 +++ I was mistaken early in bug 496474 when I thought libobjc.A.dylib@0x1568c was already being treated as a frame 0 that needed to be part of a compound signature; only libobjc.A.dylib@0x15688 (and now their non-hex equivalent, objc_msgSend) are. I keep running into this in my Camino crash report scanning, but I'm always in too much of a hurry to stop and file this bug. Until tonight ;) Please add libobjc.A.dylib@0x1568c to the list of frames that need a second frame to make a compound signature; thanks! :)
I've submitted this change to IT - should be done soon
Why only @0x1568c?
Yeah, I don't understand this at all. Why couldn't we either 1) skip all libobjc.A.dylib@ top frames entirely 2) make the compound signature out of libobjc.A.dylib@*, stripping the numeric part
> 1) skip all libobjc.A.dylib@ top frames entirely I can easily make Socorro do that > 2) make the compound signature out of libobjc.A.dylib@*, > stripping the numeric part I can do part of that, making compound signature for libobjc.A.dylib@*. But stripping the numeric part out of of the generated compound signature will take some recoding...
I think #1 is the best solution, unless Smokey has some reason he thinks they are actually different crashes.
That'd mean that any crash in that library for which we don't have symbols gets lumped together. That doesn't sound right.
It would be lumped by the mozilla caller: what's wrong with that?
The situation here is that we have a very specific common function in libobjc (objc_msgSend) that is never useful as a stack signature *by itself*. We want to know, however, that the place we crashed was objc_msgSend (that tells us what we're doing wrong), but we also want to what led to that, because it's in the latter where we tease out different crashes. (We also happen to know that when we have reports that don't get resymbolized properly, 0x1568c and 0x15688 are the usual crashing addresses for objc_msgSend.) Ignoring libobjc altogether doesn't help, because now we have an assortment of crashes with no connection to why we crashed. Making every non-resymbolized libobjc crash part of a "libobjc | foo" compound signature is not *as* bad, but then we lose the connection to the function in libobjc in which we're crashing; it's not always objc_msgSend. Either of those proposals entails more work on our part to figure out what sort of crash we're seeing, and/or more manual sorting to tell things apart, whereas I'm trying to cut down on the manual sorting I have to do. (What I'd really, really like is a way to tell Socorro to make the libobjc.A.dylib@0x1568c and libobjc.A.dylib@0x15688 frames to show up as objc_msgSend and go from there, so I don't have the exact same crash with the exact same signature showing up in three different places in my results due to resymbolization failures.)
Sounds like pain to work around the lack of symbols for libobjc. Can you just get the symbols for the two versions libobjc which we're missing and we can upload them?
If we send everyone in the Mozilla community off to get the module IDs for their libobjc dylib, I'm sure we'll eventually find someone who has every one of the random module IDs that don't match the ones from the symbol sets we've updated. That doesn't sound like a particularly easy task, though. (Note that we've seen dylibs from the same version/build of Mac OS X have different module IDs on different machines, which is one of the two causes of these hex symbols; the other is people still using old builds of Mac OS X 10.4.11 on PPC and people using old versions of Mac OS X 10.5.)
If the module ID is all we need, why don't we modify Breakpad to send it?
It does, that's how it knows to match up symbols in the first place. Click the "Modules" tab on any crash report page.
I don't understand what it would take to get symbols for them, then.
We have to find a computer that has that matching version, and run dump_syms on the library file on that computer, and upload the result to the symbol server.
Is this still wanted?
(In reply to Laura Thomson :laura from comment #15) > Is this still wanted? I don't think so, we now have symbols for those libraries, we should add their functions to the skiplist where needed, but that should go into separate bugs. And given the last few comments here resolved to the issue being that symbols are missing, which is solved now, I'm marking this INVALID.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.