In the crash at http://crash-stats.mozilla.com/report/index/8f2d4854-69e8-4400-9d53-f1a102091115 socorro is skipping the second frame, or first frame that there are symbols for. The stack reported by socorro is: 0x820218 xul.dll|nsBaseChannel::OnStartRequest() xul.dll|nsInputStreamPump::OnStateStart() ... The stack reported by MSVC is: 0x820218 xul.dll|nsDocumentOpenInfo::OnStartRequest() xul.dll|nsBaseChannel::OnStartRequest() xul.dll|nsInputStreamPump::OnStateStart() ... Frames further up socorro is doing just fine on. It's just the nsDocumentOpenInfo::OnStartRequest frame that is missing. For what it's worth, the initial 0x820218 frame is likely in some addon-code that we don't have symbols for. Not sure if that's what's confusing things here. The crash is from bug 529698. Email me if you want a copy of the minidump file.
The top frame is really in a memory that doesn't contain a loaded module, as far as we know. It's possible that something got unloaded and we're crashing because we're jumping into that memory, or that we really did jump off into la-la land because of a bad pointer or something. (If it was just something we didn't have symbols for, then it would look like foo.dll@0x1234.)
Jeff would also be useful here if he isn't tied up in other things. Probably what's happening is that since the top frame is not anywhere we have symbols for, we wind up scanning the stack for a return address, and skip the second frame somehow.
(In reply to comment #2) > Jeff would also be useful here if he isn't tied up in other things. Probably > what's happening is that since the top frame is not anywhere we have symbols > for, we wind up scanning the stack for a return address, and skip the second > frame somehow. Jonas, can you email me a copy of the minidump?
Indeed, the top frame (the 0x820218 one) is probably impossible for us to get. It's the missing nsDocumentOpenInfo::OnStartRequest frame that is sad that we're missing.
This could be a manifestation of bug 526484, with the missing symbol data for that range causing us to skip the frame.
It looks to me like we are using the frame pointer when we shouldn't be. If we call to an address that has no code, like 0x820128, our frame pointer will point to the previous frame and we'll skip the calling frame. One way to work around this could be to use the program string: program_string = "$eip $esp ^ = " "$esp $esp 4 - = "; when the crashing address is not at a code location.
Sounds sensible. Would you like to try whipping up a patch, or should I?
Go for it.
Assignee: nobody → ted.mielczarek
Target Milestone: --- → 1.8
Not something I got around to doing. Not an immediate priority for me.
Ted, does this bug also belong in Breakpad Integration rather than in Socorro?
Yeah, sorry. Basically all stackwalking bugs are bugs in Breakpad, not Socorro.
Component: Socorro → Breakpad Integration
Product: Webtools → Toolkit
QA Contact: socorro → breakpad.integration
Target Milestone: Future → ---
There have been a lot of changes to the stack walker in the interim.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.