Linux TOT has 20+ tests failing on my end

I’ll start looking, but as of lldb r203139 I’m seeing a hefty number of failures on Ubuntu 12.04 x86_64:

Failing Tests (22)

FAIL: LLDB (suite) :: TestSBData.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestDisasmAPI.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestThreadAPI.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestClassTypesDisassembly.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestClassTypes.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestStepAndBreakpoints.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestConstVariables.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestInlineStepping.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestCommandScript.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestInferiorAssert.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestInferiorCrashing.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestConvenienceVariables.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestLongjmp.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestTypeCompletion.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestLoadUnload.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestThreadJump.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestExitDuringStep.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestCreateDuringStep.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestDataFormatterScript.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: Test-rdar-9974002.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestDataFormatterStdString.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)
FAIL: LLDB (suite) :: TestDataFormatterStdList.py (Linux tfiala2.mtv.corp.google.com 3.2.5-gg1336 #1 SMP Thu Aug 29 02:37:18 PDT 2013 x86_64 x86_64)

At least some of htese are hitting seg faults with back traces like the following (seems to be what Xu,Chiheng mentioned earlier today):

Core was generated by `python /mnt/ssd/work/git/gen/llvm/tools/lldb/test/dotest.py -q --executable /mn’.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f01b2b72de4 in llvm::MCExternalSymbolizer::tryAddingSymbolicOperand (this=0x2d00860, MI=…, cStream=…,
Value=4198306, Address=4197171, IsBranch=true, Offset=1, InstSize=4)
at /mnt/ssd/work/git/gen/llvm/lib/MC/MCExternalSymbolizer.cpp:135

135 Expr = RelInfo->createExprForCAPIVariantKind(Expr, SymbolicOp.VariantKind);
(gdb) bt
#0 0x00007f01b2b72de4 in llvm::MCExternalSymbolizer::tryAddingSymbolicOperand (this=0x2d00860, MI=…, cStream=…,
Value=4198306, Address=4197171, IsBranch=true, Offset=1, InstSize=4)
at /mnt/ssd/work/git/gen/llvm/lib/MC/MCExternalSymbolizer.cpp:135
#1 0x00007f01b2b618fe in llvm::MCDisassembler::tryAddingSymbolicOperand (this=0x2c89700, Inst=…, Value=4198306,
Address=4197171, IsBranch=true, Offset=1, InstSize=4) at /mnt/ssd/work/git/gen/llvm/lib/MC/MCDisassembler.cpp:47
#2 0x00007f01b26e8bb9 in tryAddingSymbolicOperand (Value=4198306, isBranch=true, Address=4197171, Offset=1, Width=4,
MI=…, Dis=0x2c89700) at /mnt/ssd/work/git/gen/llvm/lib/Target/X86/Disassembler/X86Disassembler.cpp:210
#3 0x00007f01b26e9242 in translateImmediate (mcInst=…, immediate=1130, operand=…, insn=…, Dis=0x2c89700)
at /mnt/ssd/work/git/gen/llvm/lib/Target/X86/Disassembler/X86Disassembler.cpp:387
#4 0x00007f01b26ee349 in translateOperand (mcInst=…, operand=…, insn=…, Dis=0x2c89700)
at /mnt/ssd/work/git/gen/llvm/lib/Target/X86/Disassembler/X86Disassembler.cpp:740
#5 0x00007f01b26ee573 in translateInstruction (mcInst=…, insn=…, Dis=0x2c89700)
at /mnt/ssd/work/git/gen/llvm/lib/Target/X86/Disassembler/X86Disassembler.cpp:796
#6 0x00007f01b26e8ac0 in llvm::X86Disassembler::X86GenericDisassembler::getInstruction (this=0x2c89700, instr=…,
size=@0x7fff0119b510: 5, region=…, address=4197171, vStream=…, cStream=…)
at /mnt/ssd/work/git/gen/llvm/lib/Target/X86/Disassembler/X86Disassembler.cpp:160
#7 0x00007f01b0ffd355 in DisassemblerLLVMC::LLVMCDisassembler::GetMCInst (this=0x2cb2bf0,
opcode_data=0x29dd3a8 “\350j\004”, opcode_data_len=5, pc=4197171, mc_inst=…)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp:528
#8 0x00007f01b0ffc00d in InstructionLLVMC::Decode (this=0x2ba5fd0, disassembler=…, data=…, data_offset=24)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp:212
#9 0x00007f01b0ffe001 in DisassemblerLLVMC::DecodeInstructions (this=0x2c89590, base_addr=…, data=…, data_offset=0,
num_instructions=4294967295, append=false, data_from_file=true)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp:721
#10 0x00007f01b0e5416a in lldb_private::Disassembler::ParseInstructions (this=0x2c89590, exe_ctx=0x7fff0119b8e0,
range=…, error_strm_ptr=0x0, prefer_file_cache=true)

at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Core/Disassembler.cpp:1105
#11 0x00007f01b0e50fb3 in lldb_private::Disassembler::DisassembleRange (arch=…, plugin_name=0x0, flavor=0x0, exe_ctx=
…, range=…, prefer_file_cache=true) at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Core/Disassembler.cpp:250
#12 0x00007f01b0fe4cc3 in lldb_private::ThreadPlanStepRange::GetInstructionsForAddress (this=0x288f630, addr=4197147,
range_index=@0x7fff0119b9e0: 18446744072233160264, insn_offset=@0x7fff0119b9e8: 140733211851824)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Target/ThreadPlanStepRange.cpp:307
#13 0x00007f01b0fe4ff7 in lldb_private::ThreadPlanStepRange::SetNextBranchBreakpoint (this=0x288f630)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Target/ThreadPlanStepRange.cpp:365
#14 0x00007f01b0fe3dae in lldb_private::ThreadPlanStepRange::DidPush (this=0x288f630)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Target/ThreadPlanStepRange.cpp:81
#15 0x00007f01b0fcc9dc in lldb_private::thread::PushPlan (this=0x7f01a8000910, thread_plan_sp=
std::shared_ptr (count 2, weak 0) 0x288f630) at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Target/Thread.cpp:1073
#16 0x00007f01b0fcd2e7 in lldb_private::thread::QueueThreadPlan (this=0x7f01a8000910,
thread_plan_sp=std::shared_ptr (count 2, weak 0) 0x288f630, abort_other_plans=false)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Target/Thread.cpp:1231
#17 0x00007f01b0fcdad7 in lldb_private::thread::QueueThreadPlanForStepOverRange (this=0x7f01a8000910,
abort_other_plans=false, range=…, addr_context=…, stop_other_threads=lldb::eOnlyDuringStepping)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Target/Thread.cpp:1434
#18 0x00007f01b121a3a4 in CommandObjectThreadStepWithTypeAndScope::DoExecute (this=0x26ba680, command=…, result=…)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Commands/CommandObjectThread.cpp:541
#19 0x00007f01b0ea2e71 in lldb_private::CommandObjectParsed::Execute (this=0x26ba680,
args_string=0x7f01ae7f13d8 std::string::_Rep::_S_empty_rep_storage+24 “”, result=…)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:1031
#20 0x00007f01b0e91ace in lldb_private::CommandInterpreter::HandleCommand (this=0x22a0590,
command_line=0x7f01b86ea7d4 “n”, lazy_add_to_history=lldb_private::eLazyBoolNo, result=…, override_context=0x0,

repeat_on_empty_command=true, no_context_switching=false)
at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:1858
#21 0x00007f01b111fe61 in lldb::SBCommandInterpreter::HandleCommand (this=0x25e2e80, command_line=0x7f01b86ea7d4 “n”,
result=…, add_to_history=false) at /mnt/ssd/work/git/gen/llvm/tools/lldb/source/API/SBCommandInterpreter.cpp:138
#22 0x00007f01b0ce6796 in _wrap_SBCommandInterpreter_HandleCommand__SWIG_0 (args=0x2664100)
at tools/lldb/scripts/LLDBWrapPython.cpp:9591
#23 0x00007f01b0ce6daa in _wrap_SBCommandInterpreter_HandleCommand (self=0x0, args=0x2664100)
at tools/lldb/scripts/LLDBWrapPython.cpp:9699
#24 0x0000000000550138 in PyEval_EvalFrameEx ()
#25 0x0000000000575d92 in PyEval_EvalCodeEx ()

I’ll have a look at the code.

FYI - the patch I suggested to Xu,Chiheng a few minutes ago does fix all the errors above.

I’m checking with some LLVM folks to see if that patch looks reasonable.

Digging a little deeper, it looks like this change may have been what broke it:

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8

This issue seems to be resolved in top of tree now AFAICT.