Please report any other irregularities here.
Stack in bug 637396 has a very unlikely frame 0.
Generaly, it's unlikely that the top frame of a crash is ever wrong. The data that's saved in the minidump is the register state + stack memory for each thread, so the top frame is simply determined by the value of the instruction pointer for that thread. Frames further up the stack are determined by trying to recover register state given the existing registers + stack memory. That being said, I agree that the stack there is pretty weird. It's possible that the compiler is doing something funny, or the symbol dumping is producing weird results. Visual C++ does do "identical comdat folding", where functions with identical bodies after compilation are folded into the same section, which confuses our symbol dumping since they're all at the same location. Is it possible that's what's happening here? A quick way to sanity check things is to download the minidump from crash-stats and load it in Visual C++ or WinDBG and see what the stack looks like there.
Summary: Incorrect stack in crash stat trace → Incorrect stack in crash stack trace
(jpr is gone) (In reply to JP Rosevear [:jpr] from comment #0) > Stack in bug 637396 has a very unlikely frame 0. is it still the case, for bp-b68e2ac0-4340-4b52-9d18-eb1402130507
Wayne: that stack looks totally reasonable. The stack linked from comment 0 was not. (Also, it would have been nice if comment 0 had more useful information instead of having to click through to the other bug to find it.) My comment 1 still stands, if someone wants to investigate that they should try loading the dump in a debugger.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.