<div dir="ltr">Ted, Daniel, do you have any concerns about this patch?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 11, 2014 at 11:08 AM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ted and Daniel,<div><br></div><div>we're trying to get clang LSan-clean: completely free of leaks (PR19521). One of the last areas where leaks are still reported are in c-index-tests – I believe for the tests that test crash recovery. If libclang detects that it has crashed, it doesn't free the CXTranslationUnit in clang_disposeTranslationUnit().</div>

<div><br>There are a few other places in clang that intentionally leak things, so BuryPointer() (in lib/Frontend/CompilerInvocation.cpp) exists to mark pointers that are not going to be freed. The attached patch lets clang_disposeTranslationUnit() call BuryPointer() when it's not going to free things.</div>

<div><br></div><div>BuryPointer only increments an atomic unsigned and then writes to a global array indexed by said unsigned, so this should be a relatively safe thing to do. I suppose if libclang crashes and one is very unlucky, some rogue code could have overwritten the atomic int, but BuryPointer() does range checking. I think this is a safe change to make, but it's tricky code so I thought pre-commit review is the way to go here.</div>

<div><br></div><div>Thanks,</div><div>Nico</div></div>
</blockquote></div><br></div>