[LLVMdev] Assertion: replaceAllUses of value with new value of different type! being thrown all of a sudden (original) (raw)

Frédéric Riss friss at apple.com
Mon Jan 19 14:01:15 PST 2015

On Jan 19, 2015, at 1:41 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote:

Some more data. I upgraded to todays llvm/clang/clang-extra-tools top-of-trunk and I upgraded my compiler to deal with all of the changes in llvm/clang since last September. My current ToT llvm commit is 4b678bff4ebae28ec7e04ec936cf924ee8d289df I am still getting an assertion failure at exactly the same point, when I’m calling DIBuilder::finalize but the assertion has changed (but similar)- it is now: Assertion failed: (isa(Val) && "cast() argument of incompatible type!"), function cast, file /Users/meister/Development/externals-clasp/llvm36/include/llvm/Support/Casting.h, line 237. Below is some info that may answer your (Duncan and Frederic) questions: 1) Duncan asked “are you using two different LLVMContexts?” Answer: I may be - in frame 6 the DbgNode->Context reference looks mangled 2) Frederic asked “is TempEnumTypes null at this point” Answer: No, it has the value 0x000000011c81fda8 Below is an lldb session where I’m looking at the backtrace. (lldb) up frame #4: 0x0000000103de1811 claspboehmd_assertrtn(func=0x00000001043a5749, file=0x00000001043a574e, line=237, expr=0x00000001043a579f) + 129 at Signals.inc:533_ _530 else_ _531 fprintf(stderr, "Assertion failed: (%s), file %s, line %d.\n",_ _532 expr, file, line);_ _-> 533 abort();_ _534 }_ _535_ _536 void abort() {_ _(lldb) up_ _frame #5: 0x0000000103cf47dc claspboehmdllvm::castretty<llvm::MDNodeFwdDecl, llvm::MDNode*>::rettype llvm::cast<llvm::MDNodeFwdDecl, llvm::MDNode>(Val=0x000000011c81fda8) + 108 at Casting.h:237 234 235 template <class X, class Y> 236 inline typename castretty<X, Y *>::rettype cast(Y *Val) { -> 237 assert(isa(Val) && "cast() argument of incompatible type!"); 238 return castconvertval<X, Y*,_ _239 typename simplifytype<Y*>::SimpleType>::doit(Val); 240 } (lldb) up frame #6: 0x0000000103b6bf6a claspboehmd`llvm::DIDescriptor::replaceAllUsesWith(this=0x00007fff5fbdba18, D=0x0000000109d24380) + 218 at DebugInfo.cpp:349 346 void DIDescriptor::replaceAllUsesWith(MDNode *D) { 347 assert(DbgNode && "Trying to replace an unverified type!"); 348 assert(DbgNode != D && "This replacement should always happen"); -> 349 auto *Node = cast(constcast<MDNode *>(DbgNode));

According to the backtrace, DbgNode here should be TempEnumTypes. In a correct flow, TempEnumTypes has been initialized by createCompileUnit() to a temporary node (a MDNodeFwdDecl nowadays). This cast should not be able to fail if you have called createCompileUnit() and of course if TempEnumTypes hasn’t been corrupted. Can you check that the value you have at that point is the same that was assigned by createCompileUnit()? If not, then you have your bug (another thought: would it be possible that finalize is called twice on the same CU?).

Fred

350 Node->replaceAllUsesWith(D); 351 MDNode::deleteTemporary(Node); 352 } (lldb) up frame #7: 0x0000000103b4ff19 claspboehmdllvm::DIBuilder::finalize(this=0x000000011c81feb0) + 185 at DIBuilder.cpp:74_ _71_ _72 void DIBuilder::finalize() {_ _73 DIArray Enums = getOrCreateArray(AllEnumTypes);_ _-> 74 DIType(TempEnumTypes).replaceAllUsesWith(Enums);_ _75_ _76 SmallVector<Metadata *, 16> RetainValues;_ _77 // Declarations and definitions of the same type may be retained. Some_ _(lldb) print TempEnumTypes_ _(llvm::MDNode *) $0 = 0x000000011c81fda8_ _;;; Later on_ _(lldb) down_ _frame #6: 0x0000000103b6bf6a claspboehmdllvm::DIDescriptor::replaceAllUsesWith(this=0x00007fff5fbdba18, D=0x0000000109d24380) + 218 at DebugInfo.cpp:349 346 void DIDescriptor::replaceAllUsesWith(MDNode *D) { 347 assert(DbgNode && "Trying to replace an unverified type!"); 348 assert(DbgNode != D && "This replacement should always happen"); -> 349 auto *Node = cast(constcast<MDNode *>(DbgNode)); 350 Node->replaceAllUsesWith(D); 351 MDNode::deleteTemporary(Node); 352 } (lldb) print DbgNode (const llvm::MDNode *) $1 = 0x000000011c81fda8 (lldb) call DbgNode->dump() !{error: Execution was interrupted, reason: EXCBADACCESS (code=EXCI386GPFLT). The process has been returned to the state before expression evaluation. (lldb) frame variable (llvm::DIDescriptor *) this = 0x00007fff5fbdba18 (llvm::MDNode *) D = 0x0000000109d24380 (llvm::MDNodeFwdDecl *) Node = 0x0000000102f55985 (lldb) call D->dump() !{}

(lldb) call DbgNode (const llvm::MDNode *) $2 = 0x000000011c81fda8 (lldb) print *DbgNode (const llvm::MDNode) $3 = { llvm::Metadata = { SubclassID = '\0' IsDistinctInContext = false SubclassData16 = 0 SubclassData32 = 2415919104 } Context = 0x0000000109e00009 NumOperands = 1 MDNodeSubclassData = 0 } (lldb) print *D (llvm::MDNode) $4 = { llvm::Metadata = { SubclassID = '\0' IsDistinctInContext = false SubclassData16 = 0 SubclassData32 = 0 } Context = 0x0000000109e02430 NumOperands = 0 MDNodeSubclassData = 3267742850 } (lldb) print D->Context (llvm::LLVMContext) $5 = { pImpl = 0x000000010b003000 } (lldb) print DbgNode->Context (llvm::LLVMContext) $6 = { pImpl = 0xd00000000109d003 } (lldb)

On Jan 19, 2015, at 3:49 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: On 2015-Jan-19, at 12:38, Frédéric Riss <friss at apple.com> wrote:

On Jan 19, 2015, at 12:04 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote:

I forgot to mention this in my initial email. The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c The date on the commit is: Date: Fri Sep 26 12:34:06 2014 Also: Today I grabbed the ToT llvm/clang/clang-extra-tools and I’m working on getting my code to be compatible with it. I can switch back and forth between the current ToT llvm and the old one. Hmmm, I didn’t look closely enough and I thought you were hitting an assertions I added a few weeks after that commit in the Metadata RAUW method. But it is the equivalent assertion in Value::RAUW that you are hitting and that has been there forever. Looking at your exact revision, the assertion seems to trigger while executing: DIType(TempEnumTypes).replaceAllUsesWith(Enums); in DIBuilder::finalize(). Can you check if TempEnumTypes is null at this point? If that is the issue (which I’m not sure), then you need to call DIBuilder::createCompileUnit() at some point. Fred I had a thought, too: are you using two different LLVMContexts? That would cause the metadata type to compare unequal.

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150119/835ffe41/attachment.html>

More information about the llvm-dev mailing list