[lldb-dev] symbol lookup bug

[Greg Clayton]

So symbols currently can't be resolved lazily, and if they are, then that is the bug. As you noticed "Symbol *" items are handed out and you can't ever resize the vector.

The symbol table is fetched during:


    virtual Symtab *
    ObjectFile::GetSymtab () = 0;

Each ObjectFile subclass must hand out a complete symbol table when if first parses and hands out a Symtab.

Please fix the plug-in that is lazily adding symbols.

Greg


> On May 13, 2015, at 5:16 AM, Verena Beckham <verena at codeplay.com> wrote:
> 
> Hi everyone,
> 
> I found a bug in the symbol lookup in lldb, and as far as I can tell it's a serious design flaw in the way symbols are handled.
> However, I can only reproduce it when debugging an Android target remotely, and I don't understand the symbol lookup mechanism sufficiently to be able to reproduce it on a local target. The bug relies on a certain number of symbol lookups and then another symbol lookup in very specific circumstances.
> I am hoping that describing the bug in detail will allow someone who knows the mechanism understand the issues and create a local testcase.
> 
> 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.
> 
> Please let me know if you need any more information.
> Thanks very much!
> 
> 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
> 
> -- 
> Verena Beckham
> 
> Senior Developer
> 
> Codeplay Software Ltd
> 45 York Place, Edinburgh, EH1 3HP
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> 
> This email and any attachments may contain confidential and /or privileged information and  is for use  by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
> As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
> Company registered in England and Wales, number: 04567874
> Registered office: 81 Linkfield Street, Redhill RH1 6BY
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev