[lldb-dev] [Bug 23515] New: pointer to symbol invalidated when symbol vector size is increased

[bugzilla-daemon at llvm.org]

https://llvm.org/bugs/show_bug.cgi?id=23515

            Bug ID: 23515
           Summary: pointer to symbol invalidated when symbol vector size
                    is increased
           Product: lldb
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at cs.uiuc.edu
          Reporter: verena at codeplay.com
    Classification: Unclassified

Created attachment 14321
  --> https://llvm.org/bugs/attachment.cgi?id=14321&action=edit
Executable

When debugging the attached application remotely on an Android emulator lldb
crashes because a pointer to a symbol has been invalidated.

To reproduce:

Requirements: adb, Android SDK with emulator.exe and an x86 device image

Steps:
* Start the emulated android device
* Create a folder /data/symbol_bug on the device
* Move a.out and libsimple.so to /data/symbol_bug by typing
adb push a.out /data/symbol_bug
adb push libsimple.so /data/symbol_bug
* Set the permissions of the a.out file by typing
adb shell chmod 777 /data/symbol_bug/a.out
* Run launch_tool.py -e <path_to_emulator.exe> -s <path_to_adb.exe> -d
<name_of_device>
name_of_device will default to "Nexus_5_API_21_x86"
* Run lldb
* Type
gdb-remote 1234
disassemble -m
* Find the first instruction after the infinite loop (i.e. the line "if
(handle)"
* Type
register write eip <instruction_hex>
* Type "si" a few times
* After stepping into the call to dlclose (when it tries to print the
function's assembly) lldb crashes.

Explanation:

Symbols are stored in a vector. Symbols are referenced and passed around as
pointers. When a new symbol is added it is appended to the symbol vector. If
the vector does not yet have enough capacity it is resized, which makes all
pointers to the symbols invalid.

In my example I use the "si" command to step into a function call. lldb then
tries to dump the assembly of the new function. During that call new symbols
are resolved and added, because symbols are resolved lazily, as I understand.
However, this happens right in the middle of Instruction::Dump (in the call to
CalculateMnemonicOperandsAndCommentIfNeeded), which takes in two SymbolContexts
which contain pointers to Symbols and passes them to
Debugger::FormatDisassemblerAddress. By the time this function gets called the
pointers to Symbols are invalid. GetName is called on them, but the name is
0xfeeefeee, hence it crashes.

To check my hypothesis, I reserved a lot of space for the m_symbols vector
initially, and that stopped the crash from happening.

I've included below the callstacks to the place where the vector is resized, as
well as where it crashes.

symbol vector resizing:
lldb_private::Symtab::AddSymbol
ObjectFileELF::ResolveSymbolForAddress
lldb_private::Module::ResolveSymbolContextForAddress
lldb_private::Address::Dump
DisassemblerLLVMC::SymbolLookup
DisassemblerLLVMC::SymbolLookupCallback
llvm::MCExternalSymbolizer::tryAddingSymbolicOperand
llvm::MCDisassembler::tryAddingSymbolicOperand
tryAddingSymbolicOperand
translateImmediate
translateOperand
translateInstruction
llvm::X86Disassembler::X86GenericDisassembler::getInstruction
DisassemblerLLVMC::LLVMCDisassembler::GetMCInst
InstructionLLVMC::CalculateMnemonicOperandsAndComment
lldb_private::Instruction::CalculateMnemonicOperandsAndCommentIfNeeded
lldb_private::Instruction::Dump
lldb_private::Disassembler::PrintInstructions
lldb_private::Disassembler::Disassemble

crash:
lldb_private::ConstString::operator bool
lldb_private::Mangled::GetDemangledName
lldb_private::Mangled::GetName
lldb_private::Symbol::GetName
lldb_private::Debugger::FormatDisassemblerAddress
lldb_private::Instruction::Dump
lldb_private::Disassembler::PrintInstructions
lldb_private::Disassembler::Disassemble

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150513/b132f064/attachment.html>