[lldb-dev] invalid LLVMContext during expression evaluation

Sean Callanan scallanan at apple.com
Wed May 29 14:20:12 PDT 2013


Daniel,

On May 29, 2013, at 2:09 PM, "Malea, Daniel" <daniel.malea at intel.com> wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130529/2ccebd01/attachment.html>


More information about the lldb-dev mailing list