Crashes in objc_msgSend don't give us much information about what went wrong. It would be nice if we could adopt the techniques mentioned here: http://www.sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html
By the time the minidump gets to Socorro, we don't have access to heap memory, so getting the selector name is probably impossible. We obviously have the register values, but they currently get lost during Breakpad processing. We run minidump_stackwalk -m, which produces machine-readable output, which doesn't contain register values. We could modify that output to contain register values, but we'd have to modify Socorro to accept the modified output.
I believe the selector names should be in the data section so we shouldn't need the heap. However, it's a good question as to whether we should do extra processing on the server or the client.
Yeah, it's not great either way. Keep in mind that on the server side we have exactly: 1) The contents of the minidump (stack memory + starting register state for all threads) 2) The contents of the symbol files On the client side, we have everything but the symbol files, but I don't know if it's possible to know that we're crashing on objc_msgSend and do extra handling. Also, we're currently limited to doing things that are safe and won't die in an already corrupted process.
(In reply to comment #3) > On the client side, we have everything but the symbol files, but I don't know > if it's possible to know that we're crashing on objc_msgSend and do extra > handling. Also, we're currently limited to doing things that are safe and won't > die in an already corrupted process. We might be able to know if eip is in objc_msgSend by getting the address of objc_msgSend at load time (e.g. with a function pointer) and perhaps using the address of the function after objc_msgSend. This would depend on the ordering of these functions not changing, but I think that with some tests to avoid false positives this could work.
What's actionable on this bug?
Assignee: nobody → ted.mielczarek
Assignee: ted.mielczarek → nobody
Component: Socorro → Breakpad Integration
Product: Webtools → Toolkit
QA Contact: socorro → breakpad.integration
(In reply to comment #5) > What's actionable on this bug? This is more a breakpad bug than I socorro bug at this point.
You need to log in before you can comment on or make changes to this bug.