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: