invalid LLVMContext during expression evaluation

Hi Sean/list,

I have just started looking into a problem that's happening with the Debian test runs (but interestingly not under manual configure/cmake builds) where the LLVMContext is coming up as uninitialized, thereby causing the internal LLDB segfault in the following stack trace. Any hints where I should start digging for the root-cause? I imagine LLDB attempts to use a global LLVMContext (?), but I have not yet found the code that initializes it...

Thanks,
Dan

Trace:

Program received signal SIGSEGV, Segmentation fault.
llvm::Value::getContext (this=0x10ea950) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Value.cpp:480
480 LLVMContext &Value::getContext() const { return VTy->getContext(); }
(gdb) bt
#0 llvm::Value::getContext (this=0x10ea950) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Value.cpp:480
#1 0x00007ffff387a99e in llvm::ValueHandleBase::AddToUseList (this=0x116c7d0) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Value.cpp:515
#2 0x00007ffff385c8e3 in ValueHandleBase (V=<optimized out>, Kind=llvm::ValueHandleBase::Callback, this=0x116c7d0) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/include/llvm/Support/ValueHandle.h:71
#3 CallbackVH (P=<optimized out>, this=0x116c7c8) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/include/llvm/Support/ValueHandle.h:354
#4 MDNodeOperand (V=<optimized out>, this=0x116c7c8) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Metadata.cpp:67
#5 llvm::MDNode::MDNode (this=<optimized out>, C=..., Vals=..., isFunctionLocal=<optimized out>) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Metadata.cpp:122
#6 0x00007ffff385ca47 in llvm::MDNode::getMDNode (Context=..., Vals=..., FL=<optimized out>, Insert=<optimized out>) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Metadata.cpp:255
#7 0x00007ffff4cf7de9 in IRForTarget::RegisterFunctionMetadata (this=this@entry=0x7fffffffadb0, context=..., function_ptr=function_ptr@entry=0x10b7690, name=0x1139cc0 "_ZL18a_function_to_callv")
    at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/tools/lldb/source/Expression/IRForTarget.cpp:344
#8 0x00007ffff4cf86e1 in IRForTarget::ResolveFunctionPointers (this=this@entry=0x7fffffffadb0, llvm_module=..., llvm_function=...) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/tools/lldb/source/Expression/IRForTarget.cpp:390
#9 0x00007ffff4cff3d8 in IRForTarget::runOnModule (this=0x7fffffffadb0, llvm_module=...) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/tools/lldb/source/Expression/IRForTarget.cpp:2755
#10 0x00007ffff4ce3b12 in lldb_private::ClangExpressionParser::PrepareForExecution (this=0x7fffffffaf60, func_addr=@0x10c2398: 18446744073709551615, func_end=@0x10c23a0: 18446744073709551615, execution_unit_ap=..., exe_ctx=..., can_interpret=@0x10c2438: false,
    execution_policy=lldb_private::eExecutionPolicyOnlyWhenNeeded) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/tools/lldb/source/Expression/ClangExpressionParser.cpp:525
#11 0x00007ffff4cebfc7 in lldb_private::ClangUserExpression::Parse (this=0x10c2380, error_stream=..., exe_ctx=..., execution_policy=execution_policy@entry=lldb_private::eExecutionPolicyOnlyWhenNeeded, keep_result_in_memory=keep_result_in_memory@entry=true)
    at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/tools/lldb/source/Expression/ClangUserExpression.cpp:524

Daniel,

I have just started looking into a problem that’s happening with the Debian test runs (but interestingly not under manual configure/cmake builds) where the LLVMContext is coming up as uninitialized, thereby causing the internal LLDB segfault in the following stack trace. Any hints where I should start digging for the root-cause? I imagine LLDB attempts to use a global LLVMContext (?), but I have not yet found the code that initializes it…

Each ClangExpressionParser sets up its own LLVMContext. See ClangExpressionParser.cpp:376 or thereabouts. The LLVMContext is then installed into the Clang code generator, but we retain ownership.

Program received signal SIGSEGV, Segmentation fault.
llvm::Value::getContext (this=0x10ea950) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Value.cpp:480
480 LLVMContext &Value::getContext() const { return VTy->getContext(); }
(gdb) bt
#0 llvm::Value::getContext (this=0x10ea950) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Value.cpp:480

If you’re dying in llvm::Value::getContext, it doesn’t sound to me like the context is bad, it’s VTy that’s bad.

You’re in the code that prepares LLVM IR for running in the target. ResolveFunctionPointers changes by-name function references to literals cast to function pointers – essentially we’re pre-linking the code because we don’t trust the MCJIT to do so. RegisterFunctionMetadata attaches a little bit of metadata to each call to the function, letting later passes (in particular, the Objective-C checkers) know what the name of the called function is.

Hope this helps, and happy debugging.

Sean

Hi Sean, thanks for the notes! I think I found the root-cause of the problem, which was that ConstantDataArray was being used as an operand when constructing an MDNode, which is not valid according to docs because CDA does some packing of the internal data and may mangle the actual Value* that MDNode expects.. In my experience, this happens at higher >O2 optimization levels.

In any case, the fix was simple enough, it should be in 183153. I'm surprised we didn't run into this crash before.

Cheers,
Dan