The x86 instruction unwinder can be asked to disassemble non-instruction

blocks of memory, and if the final bytes of that block look like a long
x86 instruction, it can cause the llvm disassembler to read past the end
of the buffer.  Use the maximum allowed instruction length that we pass
to the llvm disassembler as a way to limit this to the size of the buffer.

An example of how to trigger this is when lldb does a function call, it
puts a breakpoint on the beginning of main() and uses that as the return
address from the function call.  When we stop at that location, lldb may
try to find the first frame up the stack.  Because this is on the first
instruction of a function, it will get the word-size value at the stack
pointer and assume that this was the caller's pc value.  But this is random
stack memory and could point to anything - an object in memory, something
in the data section, whatever.  And if we have a symbol for that thing,
we'll try to disassemble it.

This was leading to infrequent crashes in customer scenarios; figured out
what was happening with address sanitizer.

<rdar://problem/30463256> 

llvm-svn: 307454

0 files changed, 0 insertions, 0 deletions