On Mon, May 6, 2013 at 2:07 PM, Tom Honermann <span dir="ltr"><<a href="mailto:thonermann@coverity.com" target="_blank">thonermann@coverity.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This email describes a SIGSEGV I'm experiencing with Clang 3.2 when calling Sema::<u></u>PerformPendingInstantiations()<u></u>. A patch against latest SVN is attached which resolves the SIGSEGV. However, it appears that the call to Sema::<u></u>PerformPendingInstantiations() is resulting in a call to Sema::getCurScope() which, according to its comments, should never be called during template instantiation. The purpose of this email is to:<br>
<br>
1) Request that the attached patch be applied to SVN. The patch is trivial - it just adds missing initialization of the Sema::CurScope pointer within the Sema constructor.<br></blockquote><div><br></div><div>Thanks, patch committed as r181251. If you have any way of testing this without building an additional binary, I'd appreciate it!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Clarify whether the eventual call into Sema::getCurScope() from within Sema::<u></u>PerformPendingInstantiations() represents an additional bug which should be addressed.<br></blockquote><div><br></div><div>Generally, yes, but getScopeForContext is always allowed to call getCurScope.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I experienced the SIGSEGV in code that calls ASTUnit::LoadFromASTFile() to load an AST file produced with the 'clang -emit-ast' driver option. ASTUnit::LoadFromASTFile() creates an instance of the Sema class, but a corresponding Parser instance is not created. AST files may contain pending template instantiations. I have a call to Sema::<u></u>PerformPendingInstantiations() to complete them. The SIGSEGV occurs when the Sema::CurScope pointer is dereferenced. I debugged the problem and discovered that the Sema constructor (there is only one) is failing to initialize the CurScope member. The comments for CurScope indicate that the Parser maintains this pointer. In my case, there is no Parser instance, hence no initialization occurs resulting in a spurious SIGSEGV. Initializing CurScope to NULL in the Sema constructor avoids the SIGSEGV. CurScope is referenced by Sema::getCurScope() which has the following comment:<br>
<br>
include/clang/Sema/Sema.h:<br>
7547 /// \brief Retrieve the parser's current scope.<br>
7548 ///<br>
7549 /// This routine must only be used when it is certain that semantic analysis<br>
7550 /// and the parser are in precisely the same context, which is not the case<br>
7551 /// when, e.g., we are performing any kind of template instantiation.<br>
7552 /// Therefore, the only safe places to use this scope are in the parser<br>
7553 /// itself and in routines directly invoked from the parser and *never* from<br>
7554 /// template substitution or instantiation.<br>
7555 Scope *getCurScope() const { return CurScope; }<br>
<br>
The following stack trace demonstrates that calls to Sema::<u></u>PerformPendingInstantiations() eventually call into Sema::getCurScope(). The stack trace corresponds to the occurrence of the SIGSEGV. The call to Sema::getCurScope() occurs in Sema::getScopeForContext(). Note that the 'this' pointer provided for the call to Scope::getFlags() is invalid.<br>
<br>
#0 0x000000000118ffaa in clang::Scope::getFlags (this=0x2f) at .../llvm-3.2/tools/clang/<u></u>include/clang/Sema/Scope.h:170<br>
#1 0x000000000120c411 in clang::Sema::<u></u>getScopeForContext (this=0x2af0cb0, Ctx=0x2b2b1c0) at .../llvm-3.2/tools/clang/lib/<u></u>Sema/Sema.cpp:955<br>
#2 0x0000000001310891 in clang::Sema::<u></u>DeclareImplicitCopyConstructor (this=0x2af0cb0, ClassDecl=0x2b2b188) at .../llvm-3.2/tools/clang/lib/<u></u>Sema/SemaDeclCXX.cpp:8836<br>
#3 0x0000000001456552 in clang::Sema::<u></u>LookupConstructors (this=0x2af0cb0, Class=0x2b2b188) at .../llvm-3.2/tools/clang/lib/<u></u>Sema/SemaLookup.cpp:2458<br>
#4 0x000000000143b557 in TryConstructorInitialization (S=..., Entity=..., Kind=..., Args=0x2b2b120, NumArgs=2, DestType=..., Sequence=..., InitListSyntax=false)<br>
at .../llvm-3.2/tools/clang/lib/<u></u>Sema/SemaInit.cpp:2846<br>
#5 0x000000000143f4a4 in clang::InitializationSequence:<u></u>:InitializationSequence (this=0x7fffffff9b20, S=..., Entity=..., Kind=..., Args=0x2b2b120, NumArgs=2)<br>
at .../llvm-3.2/tools/clang/lib/<u></u>Sema/SemaInit.cpp:4138<br>
#6 0x00000000012f5e1a in clang::Sema::<u></u>BuildMemberInitializer (this=0x2af0cb0, Member=0x2b2b138, Init=0x2b2b0f8, IdLoc=...)<br>
at .../llvm-3.2/tools/clang/lib/<u></u>Sema/SemaDeclCXX.cpp:2345<br>
#7 0x00000000015ad440 in clang::Sema::<u></u>InstantiateMemInitializers (this=0x2af0cb0, New=0x2ad5af0, Tmpl=0x2af5fc8, TemplateArgs=...)<br>
at .../llvm-3.2/tools/clang/lib/<u></u>Sema/<u></u>SemaTemplateInstantiateDecl.<u></u>cpp:3116<br>
#8 0x00000000015ac3a7 in clang::Sema::<u></u>InstantiateFunctionDefinition (this=0x2af0cb0, PointOfInstantiation=..., Function=0x2ad5af0, Recursive=true, DefinitionRequired=false)<br>
at .../llvm-3.2/tools/clang/lib/<u></u>Sema/<u></u>SemaTemplateInstantiateDecl.<u></u>cpp:2823<br>
#9 0x00000000015aee72 in clang::Sema::<u></u>PerformPendingInstantiations (this=0x2af0cb0, LocalOnly=false)<br>
at .../llvm-3.2/tools/clang/lib/<u></u>Sema/<u></u>SemaTemplateInstantiateDecl.<u></u>cpp:3630<br>
...<br>
<br>
Here is a simple test case that seems to reliably reproduce a SIGSEGV for me. This is what was used to produce the above back trace.<br>
#include <string><br>
void f() {<br>
std::string s;<br>
}<br>
<br>
So, anyone know if this call chain does represent an additional bug? Or are the comments provided for Sema::getCurScope() perhaps a little too strong?<span class="HOEnZb"><font color="#888888"><br>
<br>
Tom.<br>
</font></span><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">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>
<br></blockquote></div><br>