530613 - Missing frame early in windows stack

Status: RESOLVED INCOMPLETE

(Toolkit :: Crash Reporting, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 1

[(not currently active) Ted Mielczarek]

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.)

Comment 2

[(not currently active) Ted Mielczarek]

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.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

(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?

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 5

[(not currently active) Ted Mielczarek]

This could be a manifestation of bug 526484, with the missing symbol data for that range causing us to skip the frame.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 7

[(not currently active) Ted Mielczarek]

Sounds sensible. Would you like to try whipping up a patch, or should I?

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Go for it.

Comment 9

[Laura Thomson :laura]

Ted, status?

Comment 10

[(not currently active) Ted Mielczarek]

Not something I got around to doing. Not an immediate priority for me.

Comment 11

[Robert Kaiser]

Ted, does this bug also belong in Breakpad Integration rather than in Socorro?

Comment 12

[(not currently active) Ted Mielczarek]

Yeah, sorry. Basically all stackwalking bugs are bugs in Breakpad, not Socorro.

Comment 13

[(not currently active) Ted Mielczarek]

There have been a lot of changes to the stack walker in the interim.