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

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


> 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

> 
> .Chris.
> 
> 
> On Jan 18, 2015, at 12:52 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
>> I'm not sure what's going on, but I do know this code wouldn't 
>> (or, shouldn't) compile on ToT for the last couple of months,
>> since `Value` and `MDNode` belong to different class hierarchies.
>> 
>>> On 2015 Jan 17, at 15:16, Christian Schafmeister <chris.schaf at verizon.net> wrote:
>>> 
>>> Hello,
>>> 
>>> I wonder if someone would know what is going on below.
>>> 
>>> 
>>> All of a sudden I’m getting this assertion thrown:
>>> 
>>> Assertion failed: (New->getType() == getType() && "replaceAllUses of value with new value of different type!"), function replaceAllUsesWith, file /Users/meister/Development/externals-clasp/llvm36/lib/IR/Value.cpp, line 345.
>>> 
>>> It’s happening when DIBuilder::finalize is being called at the end of a source file compilation.
>>> 
>>> Here’s the most illuminating debugging information I could pull out of a frame:
>>> 
>>> 
>>> (lldb) 
>>> frame #6: 0x0000000103a67c3e clasp_boehm_d`llvm::DIDescriptor::replaceAllUsesWith(this=0x00007fff5fb9e288, D=0x000000010985b330) + 254 at DebugInfo.cpp:399
>>>  396 	  MDNode *Node = const_cast<MDNode *>(DbgNode);
>>>  397 	  const MDNode *DN = D;
>>>  398 	  const Value *V = cast_or_null<Value>(DN);
>>> -> 399 	  Node->replaceAllUsesWith(const_cast<Value *>(V));
>>>  400 	  MDNode::deleteTemporary(Node);
>>>  401 	}
>>>  402 	
>>> (lldb) print Node
>>> (llvm::MDNode *) $3 = 0x00000001180b74c0
>>> (lldb) call Node->dump()
>>> !{i32 786468}
>>> 
>>> (lldb) call V->dump()
>>> !{}
>>> 
>>> (lldb) 
>>> 
>>> 
>>> 
>>> 
>>> Here’s the first part of the backtrace:
>>> 
>>> (lldb) bt
>>> * thread #1: tid = 0x4ec96f, 0x00007fff93137866 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
>>>   frame #0: 0x00007fff93137866 libsystem_kernel.dylib`__pthread_kill + 10
>>>   frame #1: 0x00007fff8cd8035c libsystem_pthread.dylib`pthread_kill + 92
>>>   frame #2: 0x0000000103ca78ab clasp_boehm_d`raise(sig=6) + 27 at Signals.inc:373
>>>   frame #3: 0x0000000103ca7962 clasp_boehm_d`abort + 18 at Signals.inc:390
>>>   frame #4: 0x0000000103ca7941 clasp_boehm_d`__assert_rtn(func=0x000000010432361c, file=0x00000001043231df, line=345, expr=0x0000000104323720) + 129 at Signals.inc:386
>>>   frame #5: 0x0000000103bfa48d clasp_boehm_d`llvm::Value::replaceAllUsesWith(this=0x00000001180b74c0, New=0x000000010985b330) + 317 at Value.cpp:344
>>>   frame #6: 0x0000000103a67c3e clasp_boehm_d`llvm::DIDescriptor::replaceAllUsesWith(this=0x00007fff5fb9e288, D=0x000000010985b330) + 254 at DebugInfo.cpp:399
>>> * frame #7: 0x0000000103a4e8e9 clasp_boehm_d`llvm::DIBuilder::finalize(this=0x0000000116bba4e0) + 185 at DIBuilder.cpp:40
>>>   frame #8: 0x00000001010cd4c8 clasp_boehm_d`core::IndirectVariadicMethoid<core::policies::policies_<>, llvmo::DIBuilder_O, void (this=0x000000010c6ea5b8, lcc_resultP=0x00007fff5fb9eb58, arg0=<unavailable>)()>::invoke(gctools::multiple_values<core::T_O>*, gctools::smart_ptr<core::T_O>) + 232 at external_wrappers_indirect_methoids.h:2704
>>>   frame #9: 0x00000001010cd1f1 clasp_boehm_d`core::IndirectVariadicMethoid<core::policies::policies_<>, llvmo::DIBuilder_O, void (this=0x000000010c6ea5b8, lcc_resultP=0x00007fff5fb9eb58, lcc_nargs=1, lcc_fixed_arg0=0x000000010d1dd098, lcc_fixed_arg1=0x0000000000000000, lcc_fixed_arg2=0x0000000000000000, lcc_fixed_arg3=0x0000000000000000, lcc_fixed_arg4=0x0000000000000000)()>::invoke(gctools::multiple_values<core::T_O>*, unsigned long, core::T_O*, core::T_O*, core::T_O*, core::T_O*, core::T_O*) + 577 at external_wrappers_indirect_methoids.h:2698
>>>   frame #10: 0x00000001009a2426 clasp_boehm_d`core::SingleDispatchGenericFunctionClosure::invoke(this=0x000000010c6ea558, lcc_resultP=0x00007fff5fb9eb58, lcc_nargs=1, lcc_fixed_arg0=0x000000010d1dd098, lcc_fixed_arg1=0x0000000000000000, lcc_fixed_arg2=0x0000000000000000, lcc_fixed_arg3=0x0000000000000000, lcc_fixed_arg4=0x0000000000000000) + 2022 at singleDispatchGenericFunction.cc:183
>>>   frame #11: 0x00000001010f5d5f clasp_boehm_d`sp_FUNCALL(resultP=0x00007fff5fb9f168, closure=0x000000010c6ea558, lcc_nargs=1, lcc_fixed_arg0=0x000000010d1dd098, lcc_fixed_arg1=0x0000000000000000, lcc_fixed_arg2=0x0000000000000000, lcc_fixed_arg3=0x0000000000000000, lcc_fixed_arg4=0x0000000000000000) + 815 at intrinsics.cc:272
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 





More information about the llvm-dev mailing list