Open Bug 1274428 Opened 8 years ago Updated 8 years ago

Mark crashes that happen at invalid instruction pointers?


(Socorro :: General, task)

Not set


(Not tracked)


(Reporter: khuey, Unassigned)



In bug 1272750 we have a minidump that is crashing at an address that turns out not to be a valid ip.  What happened was a bit was flipped earlier giving us a sequence of garbage instructions and we crashed at one of them.  There are other mechanisms that can lead to us getting an invalid ip, but in general, crashes with invalid ips are interesting in certain ways (notably you shouldn't expect any sane matching between the source code and what's going on).

Would it be possible to mark these somehow?  Not sure if there's a better way to do it than disassembling the binaries and having a list of valid ips that you check against.  And if that's too expensive to make this worthwhile.
Flags: needinfo?
Flags: needinfo? → needinfo?(ted)
Can you define what you mean by `invalid ip`?
Flags: needinfo?(ted)
If you disassemble a binary, you'll list a (long) list of instruction pointers.  If we crash somewhere within a binary but not at one of those pointers, something weird happened.
Oh, you mean "the instruction pointer is not at the start of an instruction"? I don't think there's any a priori way to know this on x86 except for disassembling from the start of each function. Breakpad does have an x86 disassembler (32-bit only, I have a patch to use a better disassembler but haven't had time to finish it up), and it uses it in the exploitability rating generation:

...but it doesn't seem to factor in "is this a valid instruction" into the rating.

We have a tool called `jit-crash-categorize` that runs on JIT crashes with certain signatures that also uses the disassembler:

It does attempt to detect invalid instructions, but only because it has knowledge of what instructions our JITs output.
Note that this will detect a bunch of different sorts of crashes, including various exploitable crashes involving jumping to freed memory, memory corruption of the binary on disk or in RAM, etc.

I proposed an alternative analysis in bug 1274628 that would be more focused on memory corruption of instructions.
(That said, this particular analysis is useful in pointing out crashes where you have to be extra careful when debugging a minidump.)
You need to log in before you can comment on or make changes to this bug.