<div dir="ltr">On Mon, Mar 18, 2013 at 11:49 AM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:akyrtzi@gmail.com" target="_blank">akyrtzi@gmail.com</a>></span> wrote:<br><div><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Are you able to provide a preprocessed file where this occurs ?</div>
</div></blockquote><div><br></div><div>I set about making such a file this morning, but first found that when I upgrade from 3.2 to the latest version in SVN the crash goes away. I doubt anyone is going to care about backporting a fix for 3.2, so am assuming getting clean file (i.e. without internal code from where I work) that it reproduces on no longer matters.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I assume your custom build has assertions enabled, right ?</div>
</div></blockquote><div style>I did.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div>You could also maybe try running under valgrind.</div></div></blockquote><div style>It was too slow to run under long enough to reproduce the bug.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div class="h5"><div>On Feb 25, 2013, at 2:32 PM, Ben Hendrickson <<a href="mailto:ben.hendrickson@gmail.com" target="_blank">ben.hendrickson@gmail.com</a>> wrote:</div><br>
</div></div><blockquote type="cite"><div><div class="h5"><div dir="ltr"><div>There is an infrequent crash in libclang.so when calling clang_reparseTranslationUnit, which I encounter when using the YouCompleteMe vim plugin (which does auto-completion using libclang.so). It looks to me to be a libclang bug, and have traced it back enough that perhaps someone familiar with the Sema code could quickly find the error (I've cc'ed the author of YouCompleteMe in case he could add something).</div>
<div><br></div><div>I encountered this on the prebuilt x64 ubuntu 3.2 binaries, and investigated using the source code from <a href="http://llvm.org/svn/llvm-project/cfe/branches/release_32" target="_blank">http://llvm.org/svn/llvm-project/cfe/branches/release_32</a> r170678.</div>
<div><br></div><div>By recompiling libclang.so and every time I see the crash adding increasingly relevant logging statements, here is what I've found:</div><div><br></div><div>Sema::LookupSpecialMember has the line:</div>
<div><div> llvm::tie(I, E) = RD->lookup(Name);</div><div>Which calls DeclContext::lookup which calls StoredDeclsList::getLookupResult to get iterators to the beginning and end of an vector to loop over. This is iterating over NamedDecl pointers. When it crashes, this array of pointers has around 10 elements in it, and one of them (towards the middle of the array) is invalid (the value of the pointer is always less than or equal to 0x35 - so clearly invalid - although is never actually NULL) and thus crashes when it does the first thing in this loop, the "if (Cand->isInvalidDecl())" call as this=0x35 for the call to isInvalidDecl which doesn't work out.</div>
<div><br></div><div>After the call to RD->lookup(Name) line, I can add a check to make sure the pointers in the array are all above 0x35, and indeed they are. Nevertheless, at some point actually step through the pointers in the array, one will be less than 0x35, and we'll crash. So at some point in the loop, a pointer later in the array is getting changed. This means one can hack around the bug by making a local copy of the array one is iterating over immediately after the RD->lookup call. Indeed, I've done that, and have not seen a crash since. For example:</div>
<div><br></div><div>llvm::tie(I, E) = RD->lookup(Name);<br></div><div><div>> int decl_count = E - I;</div><div>> NamedDecl* Cands[decl_count];</div><div>> for (int i = 0; i < decl_count; i++) {</div>
<div>> Cands[i] = I[i];</div><div>> }</div><div>> I = Cands;</div><div>> E = Cands + decl_count;</div><div>assert((I != E) &&<br></div></div><div><div> "lookup for a constructor or assignment operator was empty");</div>
<div><br></div><div>Of course, this hack couldn't be checked in, and really whatever is modifying the later elements in the array should be fixed. . </div>
<div><br></div><div>I've also looked at the code for the YouCompleteMe vim plugin, and do not believe the bug in from that project. Although modifying that project to always rebuild translation units from scratch instead of reparsing existing ones also avoids the crash.</div>
<div><br></div><div>Files I see this crashes on generally are long and are making use of template meta programming, but even on these files, the crashes are infrequent.</div><div><br></div><div>I hope this is useful. As a c++ programmer, I deeply appreciate the Clang project.</div>
<div><br></div><div>Cheers,</div><div>Ben</div>
</div></div></div></div></div>
_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></blockquote></div><br></div></div></div>