forked from OSchip/llvm-project
f62080451c
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 |
||
|---|---|---|
| .. | ||
| Breakpoint | ||
| Core | ||
| Editline | ||
| Expression | ||
| Host | ||
| Interpreter | ||
| Language | ||
| ObjectFile | ||
| Platform | ||
| Process | ||
| ScriptInterpreter | ||
| Signals | ||
| Symbol | ||
| SymbolFile | ||
| Target | ||
| UnwindAssembly | ||
| Utility | ||
| debugserver | ||
| tools | ||
| CMakeLists.txt | ||
| gtest_common.h | ||