thr3ads.net - llvm dev - [LLVMdev] Crash on invalid during LLVMContext destruction MDNode::dropAllReferences [Jan 2015]

If this information is useful, please help other people find it:
Share via:

David Blaikie

2015-Jan-14 17:24 UTC

[LLVMdev] Crash on invalid during LLVMContext destruction MDNode::dropAllReferences

On Wed, Jan 14, 2015 at 9:05 AM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:
>
> > On 2015 Jan 14, at 07:58, Duncan P. N. Exon Smith <dexonsmith at
apple.com>
> wrote:
> >
> >>
> >> On 2015 Jan 13, at 23:59, David Blaikie <dblaikie at
gmail.com> wrote:
> >>
> >>
> >>
> >> On Tue, Jan 13, 2015 at 11:48 PM, Duncan Exon Smith <
> dexonsmith at apple.com> wrote:
> >> Not at a computer right now, but it looks like teardown isn't
working
> correctly.  Do you have an asserts build?  Does an assertion fire there?
> >>
> >> That was with an asserts build.
> >>
> >> Looking at the stack trace, dropAllReferences() is being called on
a
> node, so it sets its operands to nullptr, and some operand has RAUW support
> (so the tracking needs to be dropped) but looks like it might have been
> deleted or is otherwise corrupt.  Hard to tell though.
> >>
> >> Does this reproduce from preprocessed source?   Can you send it to
me?
> >>
> >> Or maybe that's a test case in your email.  I'll try it in
the morning.
> >>
> >> Yeah, just the test code in the original email is what I
reproduced the
> linked list error with - some variations of it produced the assertion...
> maybe valgrinding or asanified clang would make the failure more reliable,
> etc.
> >>
> >
> > The version here doesn't repro for me (don't have an asan
build handy --
> > I'll build one -- but I tried the weaker gmalloc).  I tried
messing with
> > it but nothing happened.
> >
> > Can you send a version that gets the stack trace?
> >
> > (What revision is this, by the way?  ToT as of last night?)
>
> Asan didn't find it either, and then I realized I was using the RUN
line
> instead of the command-line you were using (with -g).

Ah, right - sorry about that red herring.

> So the asan dump follows.
>
Looks related to the stack I was seeing.

> I'll look into this when I get to work.  Definitely from my stuff
somehow.
>
OK - wasn't any particular rush for me, I just ran into this while writing
test cases for my debug line quality stuff in clang (accidentally
introduced a call to a function that didn't exist, which produced the
crash).

Based on how I saw it, I'm guessing it's something to do with
"LLVMContext
has trouble being destroyed if <some task that we only do when successfully
finishing codegen and is skipped if we abort codegen due to an error in the
source> is not done first".

>
> $ /Users/dexonsmith/data/llvm.asan/staging/bin/clang -cc1 crash.cpp -g
> -emit-obj -fexceptions -fcxx-exceptions
> crash.cpp:13:1: error: C++ requires a type specifier for all declarations
> x;
> ^
> 1 error generated.
> ================================================================>
==3013==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x60600000b5c0 at pc 0x00010b1a5454 bp 0x7fff54cdbb40 sp 0x7fff54cdbb38
> READ of size 1 at 0x60600000b5c0 thread T0
>     #0 0x10b1a5453 in llvm::Metadata::getMetadataID() const
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x100284453)
>     #1 0x10c4a8468 in
> llvm::ReplaceableMetadataImpl::replaceAllUsesWith(llvm::Metadata*)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x101587468)
>     #2 0x10c4a9317 in llvm::ValueAsMetadata::handleDeletion(llvm::Value*)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x101588317)
>     #3 0x10c4f5be0 in llvm::Value::~Value()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1015d4be0)
>     #4 0x10c35f22d in llvm::ConstantInt::~ConstantInt()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10143e22d)
>     #5 0x10c47e9b3 in void
> llvm::DeleteContainerSeconds<llvm::DenseMap<llvm::APInt,
> llvm::ConstantInt*, llvm::DenseMapAPIntKeyInfo,
> llvm::detail::DenseMapPair<llvm::APInt, llvm::ConstantInt*> >
> >(llvm::DenseMap<llvm::APInt, llvm::ConstantInt*,
> llvm::DenseMapAPIntKeyInfo, llvm::detail::DenseMapPair<llvm::APInt,
> llvm::ConstantInt*> >&)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10155d9b3)
>     #6 0x10c47c524 in llvm::LLVMContextImpl::~LLVMContextImpl()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10155b524)
>     #7 0x10c47a07e in llvm::LLVMContext::~LLVMContext()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10155907e)
>     #8 0x10d68b2bb in clang::CodeGenAction::~CodeGenAction()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10276a2bb)
>     #9 0x10d68f83d in clang::EmitObjAction::~EmitObjAction()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10276e83d)
>     #10 0x10cfeb6ad in
> clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1020ca6ad)
>     #11 0x10af2f768 in cc1_main(llvm::ArrayRef<char const*>, char
const*,
> void*) (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10000e768)
>     #12 0x10af249a6 in ExecuteCC1Tool(llvm::ArrayRef<char const*>,
> llvm::StringRef)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1000039a6)
>     #13 0x10af23aea in main
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x100002aea)
>     #14 0x7fff99d2a5c8 in start (/usr/lib/system/libdyld.dylib+0x35c8)
>     #15 0x6  (<unknown module>)
>
> 0x60600000b5c0 is located 32 bytes inside of 64-byte region
> [0x60600000b5a0,0x60600000b5e0)
> freed by thread T0 here:
>     #0 0x113dcd0e9 in wrap__ZdlPv
>
(/SWE/Apps/DT/Binaries/OzarkFamily/Binaries2/clang/clang-602.0.31~1/Root/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x430e9)
>     #1 0x10c4a84ee in
> llvm::ReplaceableMetadataImpl::replaceAllUsesWith(llvm::Metadata*)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1015874ee)
>     #2 0x10c4a9317 in llvm::ValueAsMetadata::handleDeletion(llvm::Value*)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x101588317)
>     #3 0x10c4f5be0 in llvm::Value::~Value()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1015d4be0)
>     #4 0x10c35f22d in llvm::ConstantInt::~ConstantInt()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10143e22d)
>     #5 0x10c47e9b3 in void
> llvm::DeleteContainerSeconds<llvm::DenseMap<llvm::APInt,
> llvm::ConstantInt*, llvm::DenseMapAPIntKeyInfo,
> llvm::detail::DenseMapPair<llvm::APInt, llvm::ConstantInt*> >
> >(llvm::DenseMap<llvm::APInt, llvm::ConstantInt*,
> llvm::DenseMapAPIntKeyInfo, llvm::detail::DenseMapPair<llvm::APInt,
> llvm::ConstantInt*> >&)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10155d9b3)
>     #6 0x10c47c524 in llvm::LLVMContextImpl::~LLVMContextImpl()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10155b524)
>     #7 0x10c47a07e in llvm::LLVMContext::~LLVMContext()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10155907e)
>     #8 0x10d68b2bb in clang::CodeGenAction::~CodeGenAction()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10276a2bb)
>     #9 0x10d68f83d in clang::EmitObjAction::~EmitObjAction()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10276e83d)
>     #10 0x10cfeb6ad in
> clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1020ca6ad)
>     #11 0x10af2f768 in cc1_main(llvm::ArrayRef<char const*>, char
const*,
> void*) (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10000e768)
>     #12 0x10af249a6 in ExecuteCC1Tool(llvm::ArrayRef<char const*>,
> llvm::StringRef)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1000039a6)
>     #13 0x10af23aea in main
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x100002aea)
>     #14 0x7fff99d2a5c8 in start (/usr/lib/system/libdyld.dylib+0x35c8)
>     #15 0x6  (<unknown module>)
>
> previously allocated by thread T0 here:
>     #0 0x113dccb69 in wrap__Znwm
>
(/SWE/Apps/DT/Binaries/OzarkFamily/Binaries2/clang/clang-602.0.31~1/Root/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/6.1.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x42b69)
>     #1 0x10c4a9f35 in llvm::MDNode::operator new(unsigned long, unsigned
> int) (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x101588f35)
>     #2 0x10c4abc1a in llvm::MDTuple::getImpl(llvm::LLVMContext&,
> llvm::ArrayRef<llvm::Metadata*>, bool)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10158ac1a)
>     #3 0x10c3af5ed in llvm::DebugLoc::get(unsigned int, unsigned int,
> llvm::MDNode*, llvm::MDNode*)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10148e5ed)
>     #4 0x10d4fa18c in
> clang::CodeGen::CGDebugInfo::EmitDeclare(clang::VarDecl const*,
> llvm::dwarf::LLVMConstants, llvm::Value*, unsigned int,
> llvm::IRBuilder<true, llvm::ConstantFolder,
> clang::CodeGen::CGBuilderInserter<true> >&)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1025d918c)
>     #5 0x10d517b0d in
> clang::CodeGen::CodeGenFunction::EmitParmDecl(clang::VarDecl const&,
> llvm::Value*, bool, unsigned int)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1025f6b0d)
>     #6 0x10d4a6a1f in
>
clang::CodeGen::CodeGenFunction::EmitFunctionProlog(clang::CodeGen::CGFunctionInfo
> const&, llvm::Function*, clang::CodeGen::FunctionArgList const&)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x102585a1f)
>     #7 0x10d6968cc in
> clang::CodeGen::CodeGenFunction::StartFunction(clang::GlobalDecl,
> clang::QualType, llvm::Function*, clang::CodeGen::CGFunctionInfo
const&,
> clang::CodeGen::FunctionArgList const&, clang::SourceLocation,
> clang::SourceLocation)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1027758cc)
>     #8 0x10d698b26 in
> clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
> llvm::Function*, clang::CodeGen::CGFunctionInfo const&)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x102777b26)
>     #9 0x10d494e58 in
> clang::CodeGen::CodeGenModule::codegenCXXStructor(clang::CXXMethodDecl
> const*, clang::CodeGen::StructorType)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x102573e58)
>     #10 0x10d75f36d in (anonymous
> namespace)::ItaniumCXXABI::emitCXXStructor(clang::CXXMethodDecl const*,
> clang::CodeGen::StructorType)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10283e36d)
>     #11 0x10d6ae224 in
> clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
> llvm::GlobalValue*)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10278d224)
>     #12 0x10d6b18c7 in
> clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1027908c7)
>     #13 0x10d759319 in (anonymous
> namespace)::ItaniumCXXABI::EmitCXXConstructors(clang::CXXConstructorDecl
> const*) (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x102838319)
>     #14 0x10d6b5d0a in
> clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x102794d0a)
>     #15 0x10d78fa0c in (anonymous
> namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10286ea0c)
>     #16 0x10d68e7b2 in
> clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10276d7b2)
>     #17 0x10dd927a9 in clang::ParseAST(clang::Sema&, bool, bool)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x102e717a9)
>     #18 0x10d68c96c in clang::CodeGenAction::ExecuteAction()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10276b96c)
>     #19 0x10cf7a59c in clang::FrontendAction::Execute()
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10205959c)
>     #20 0x10cf06beb in
> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x101fe5beb)
>     #21 0x10cfeb5c4 in
> clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1020ca5c4)
>     #22 0x10af2f768 in cc1_main(llvm::ArrayRef<char const*>, char
const*,
> void*) (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x10000e768)
>     #23 0x10af249a6 in ExecuteCC1Tool(llvm::ArrayRef<char const*>,
> llvm::StringRef)
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1000039a6)
>     #24 0x10af23aea in main
> (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x100002aea)
>     #25 0x7fff99d2a5c8 in start (/usr/lib/system/libdyld.dylib+0x35c8)
>     #26 0x6  (<unknown module>)
>
> SUMMARY: AddressSanitizer: heap-use-after-free ??:0
> llvm::Metadata::getMetadataID() const
> Shadow bytes around the buggy address:
>   0x1c0c00001660: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
>   0x1c0c00001670: 00 00 00 00 fa fa fa fa fd fd fd fd fd fd fd fd
>   0x1c0c00001680: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa
>   0x1c0c00001690: fd fd fd fd fd fd fd fd fa fa fa fa fd fd fd fd
>   0x1c0c000016a0: fd fd fd fd fa fa fa fa fd fd fd fd fd fd fd fd
> =>0x1c0c000016b0: fa fa fa fa fd fd fd fd[fd]fd fd fd fa fa fa fa
>   0x1c0c000016c0: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
>   0x1c0c000016d0: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 01 fa
>   0x1c0c000016e0: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa
>   0x1c0c000016f0: fd fd fd fd fd fd fd fd fa fa fa fa fd fd fd fd
>   0x1c0c00001700: fd fd fd fd fa fa fa fa 00 00 00 00 00 00 00 fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:           00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:       fa
>   Heap right redzone:      fb
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   Stack partial redzone:   f4
>   Stack after return:      f5
>   Stack use after scope:   f8
>   Global redzone:          f9
>   Global init order:       f6
>   Poisoned by user:        f7
>   Container overflow:      fc
>   Array cookie:            ac
>   ASan internal:           fe
> ==3013==ABORTING
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/12766f69/attachment.html>

Duncan P. N. Exon Smith

2015-Jan-14 19:34 UTC

head link

[LLVMdev] Crash on invalid during LLVMContext destruction MDNode::dropAllReferences

> On 2015-Jan-14, at 09:24, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> 
> 
> On Wed, Jan 14, 2015 at 9:05 AM, Duncan P. N. Exon Smith <dexonsmith at
apple.com> wrote:
> 
> > On 2015 Jan 14, at 07:58, Duncan P. N. Exon Smith <dexonsmith at
apple.com> wrote:
> >
> >>
> >> On 2015 Jan 13, at 23:59, David Blaikie <dblaikie at
gmail.com> wrote:
> >>
> >>
> >>
> >> On Tue, Jan 13, 2015 at 11:48 PM, Duncan Exon Smith <dexonsmith
at apple.com> wrote:
> >> Not at a computer right now, but it looks like teardown isn't
working correctly.  Do you have an asserts build?  Does an assertion fire there?
> >>
> >> That was with an asserts build.
> >>
> >> Looking at the stack trace, dropAllReferences() is being called on
a node, so it sets its operands to nullptr, and some operand has RAUW support
(so the tracking needs to be dropped) but looks like it might have been deleted
or is otherwise corrupt.  Hard to tell though.
> >>
> >> Does this reproduce from preprocessed source?   Can you send it to
me?
> >>
> >> Or maybe that's a test case in your email.  I'll try it in
the morning.
> >>
> >> Yeah, just the test code in the original email is what I
reproduced the linked list error with - some variations of it produced the
assertion... maybe valgrinding or asanified clang would make the failure more
reliable, etc.
> >>
> >
> > The version here doesn't repro for me (don't have an asan
build handy --
> > I'll build one -- but I tried the weaker gmalloc).  I tried
messing with
> > it but nothing happened.
> >
> > Can you send a version that gets the stack trace?
> >
> > (What revision is this, by the way?  ToT as of last night?)
> 
> Asan didn't find it either, and then I realized I was using the RUN
line
> instead of the command-line you were using (with -g). 
> 
> Ah, right - sorry about that red herring.
>  
> So the asan dump follows.
> 
> Looks related to the stack I was seeing.
>  
> I'll look into this when I get to work.  Definitely from my stuff
somehow.
> 
> OK - wasn't any particular rush for me, I just ran into this while
writing test cases for my debug line quality stuff in clang (accidentally
introduced a call to a function that didn't exist, which produced the
crash).
> 
> Based on how I saw it, I'm guessing it's something to do with
"LLVMContext has trouble being destroyed if <some task that we only do
when successfully finishing codegen and is skipped if we abort codegen due to an
error in the source> is not done first".
>  
Thanks for the report.  I'm really glad you told me now, since
moving MDLocation into place would have removed this way of
exposing it and it would have been way harder to track down
(MDLocation doesn't use ValueAsMetadata for its integer
operands, and that Value-indirection (with its RAUW behaviour)
is necessary to expose this).

This is the fix:

diff --git a/lib/IR/Metadata.cpp b/lib/IR/Metadata.cpp
index ab83252..302ffb4 100644
--- a/lib/IR/Metadata.cpp
+++ b/lib/IR/Metadata.cpp
@@ -167,6 +171,8 @@ void ReplaceableMetadataImpl::replaceAllUsesWith(Metadata
*MD) {
     return L.second.second < R.second.second;
   });
   for (const auto &Pair : Uses) {
+    if (!UseMap.count(Pair.first))
+      continue;
     OwnerTy Owner = Pair.second.first;
     if (!Owner) {
       // Update unowned tracking references directly.

I just need to figure out a formula for reproducing reliably (in
a unit test) and I'll commit.

Another thing this exposed (which would have also hidden this
problem) is that we're not proactively dropping references on
`ValueAsMetadata` during teardown.  We should.  This RAUW traffic
is unnecessary.  (It doesn't happen in the "common" case, where
the graph is complete (and RAUW has been dropped from MDTuples),
which is why this bug only fires when there's an error.)

Duncan P. N. Exon Smith

2015-Jan-14 20:00 UTC

head link

[LLVMdev] Crash on invalid during LLVMContext destruction MDNode::dropAllReferences

> On 2015-Jan-14, at 11:34, Duncan P. N. Exon Smith <dexonsmith at
apple.com> wrote:
> 
>> 
>> On 2015-Jan-14, at 09:24, David Blaikie <dblaikie at gmail.com>
wrote:
>> 
>> 
>> 
>> On Wed, Jan 14, 2015 at 9:05 AM, Duncan P. N. Exon Smith <dexonsmith
at apple.com> wrote:
>> 
>>> On 2015 Jan 14, at 07:58, Duncan P. N. Exon Smith <dexonsmith at
apple.com> wrote:
>>> 
>>>> 
>>>> On 2015 Jan 13, at 23:59, David Blaikie <dblaikie at
gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Tue, Jan 13, 2015 at 11:48 PM, Duncan Exon Smith
<dexonsmith at apple.com> wrote:
>>>> Not at a computer right now, but it looks like teardown
isn't working correctly.  Do you have an asserts build?  Does an assertion
fire there?
>>>> 
>>>> That was with an asserts build.
>>>> 
>>>> Looking at the stack trace, dropAllReferences() is being called
on a node, so it sets its operands to nullptr, and some operand has RAUW support
(so the tracking needs to be dropped) but looks like it might have been deleted
or is otherwise corrupt.  Hard to tell though.
>>>> 
>>>> Does this reproduce from preprocessed source?   Can you send it
to me?
>>>> 
>>>> Or maybe that's a test case in your email.  I'll try it
in the morning.
>>>> 
>>>> Yeah, just the test code in the original email is what I
reproduced the linked list error with - some variations of it produced the
assertion... maybe valgrinding or asanified clang would make the failure more
reliable, etc.
>>>> 
>>> 
>>> The version here doesn't repro for me (don't have an asan
build handy --
>>> I'll build one -- but I tried the weaker gmalloc).  I tried
messing with
>>> it but nothing happened.
>>> 
>>> Can you send a version that gets the stack trace?
>>> 
>>> (What revision is this, by the way?  ToT as of last night?)
>> 
>> Asan didn't find it either, and then I realized I was using the RUN
line
>> instead of the command-line you were using (with -g). 
>> 
>> Ah, right - sorry about that red herring.
>> 
>> So the asan dump follows.
>> 
>> Looks related to the stack I was seeing.
>> 
>> I'll look into this when I get to work.  Definitely from my stuff
somehow.
>> 
>> OK - wasn't any particular rush for me, I just ran into this while
writing test cases for my debug line quality stuff in clang (accidentally
introduced a call to a function that didn't exist, which produced the
crash).
>> 
>> Based on how I saw it, I'm guessing it's something to do with
"LLVMContext has trouble being destroyed if <some task that we only do
when successfully finishing codegen and is skipped if we abort codegen due to an
error in the source> is not done first".
>> 
> 
> Thanks for the report.  I'm really glad you told me now, since
> moving MDLocation into place would have removed this way of
> exposing it and it would have been way harder to track down
> (MDLocation doesn't use ValueAsMetadata for its integer
> operands, and that Value-indirection (with its RAUW behaviour)
> is necessary to expose this).
> 
> This is the fix:
> 
> diff --git a/lib/IR/Metadata.cpp b/lib/IR/Metadata.cpp
> index ab83252..302ffb4 100644
> --- a/lib/IR/Metadata.cpp
> +++ b/lib/IR/Metadata.cpp
> @@ -167,6 +171,8 @@ void
ReplaceableMetadataImpl::replaceAllUsesWith(Metadata *MD) {
>     return L.second.second < R.second.second;
>   });
>   for (const auto &Pair : Uses) {
> +    if (!UseMap.count(Pair.first))
> +      continue;
>     OwnerTy Owner = Pair.second.first;
>     if (!Owner) {
>       // Update unowned tracking references directly.
> 
> I just need to figure out a formula for reproducing reliably (in
> a unit test) and I'll commit.
> 
r226029, thanks again.  (I'll pull this into 3.6 when I get a moment.)
> Another thing this exposed (which would have also hidden this
> problem) is that we're not proactively dropping references on
> `ValueAsMetadata` during teardown.  We should.  This RAUW traffic
> is unnecessary.  (It doesn't happen in the "common" case,
where
> the graph is complete (and RAUW has been dropped from MDTuples),
> which is why this bug only fires when there's an error.)
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

llvm dev - Jan 2015 - [LLVMdev] Crash on invalid during LLVMContext destruction MDNode::dropAllReferences

[LLVMdev] Crash on invalid during LLVMContext destruction MDNode::dropAllReferences

[LLVMdev] Crash on invalid during LLVMContext destruction MDNode::dropAllReferences

[LLVMdev] Crash on invalid during LLVMContext destruction MDNode::dropAllReferences