<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Daniel,<div><br></div><div><div><div>On May 29, 2013, at 2:09 PM, "Malea, Daniel" <<a href="mailto:daniel.malea@intel.com">daniel.malea@intel.com</a>> wrote:</div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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...<br></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Program received signal SIGSEGV, Segmentation fault.<br>llvm::Value::getContext (this=0x10ea950) at /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Value.cpp:480<br>480 LLVMContext &Value::getContext() const { return VTy->getContext(); }<br>(gdb) bt<br>#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<br></div></blockquote><br></div><div>If you’re dying in llvm::Value::getContext, it doesn’t sound to me like the <i>context</i> is bad, it’s VTy that’s bad.</div><div><br></div><div>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.</div></div><div><br></div><div>Hope this helps, and happy debugging.</div><div><br></div><div>Sean</div></body></html>