<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 28 July 2017 at 18:23, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</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 Cfe-dev, Richard,<div><br></div><div>I've run into a test case in LLDB where we crash evaluating an expression in the following program:</div><div><br></div><div><font face="monospace, monospace">class Foo {};</font></div><div><font face="monospace, monospace">class Bar : public Foo {};</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">class Base {</font></div><div><font face="monospace, monospace">public:</font></div><div><font face="monospace, monospace">  virtual Foo* baz() { return nullptr; }</font></div><div><font face="monospace, monospace">};</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">class Derived : public Base {</font></div><div><font face="monospace, monospace">public:</font></div><div><font face="monospace, monospace">  Bar* baz() override { return nullptr; }</font></div><div><font face="monospace, monospace">};</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">int main() {</font></div><div><font face="monospace, monospace">  Derived d;</font></div><div><font face="monospace, monospace">  Base *b = *d;</font></div><div><font face="monospace, monospace">  b->baz(); // Break here and eval 'd.baz()' to crash.</font></div><div><font face="monospace, monospace">  return 0;</font></div><div><font face="monospace, monospace">}</font></div><div><br></div><div>LLDB is crashing in IRGen when we call the CXXRecordDecl::bases() method for the Bar class. (I think this is being called to determine whether we need to fix up the pointer returned from Derived::baz()). Because the CXXRecordDecl for Bar is generated by DWARFASTParserClang as a minimal, lazily completed decl (and is then imported into a different context for good measure), and because no other operations on Bar force it to be completed, it's still incomplete when we call bases(). In particular, the DerivedData field is still null: it's the access to this field that causes the crash.</div><div><br></div><div>I don't grok the model for lazy decl completion/import well enough to know exactly how to proceed (Is there a good source explaining it?). I know that some operations on a Decl will cause that Decl to be completed automatically. Should calling 'bases()' also trigger completion? Or should that be the responsibility of callers of bases()? (I tested forcing completion in CXXBasePaths::<wbr>lookupInBases(…) and that fixed my issue, but it's not clear to me that that's the Right Thing to do here).</div></div></blockquote><div><br></div><div>The intent is that the ExternalASTSource and the AST conspire to create the illusion that all declarations are already loaded -- calling bases() is intended to be sufficient to get the bases of the class with no other action involved.</div><div><br></div><div>The way this is supposed to work is:</div><div> * bases() calls data()</div><div> * data() calls dataPtr()</div><div> * dataPtr() calls getMostRecentDecl()</div><div> * getMostRecentDecl() (in Redeclarable.h) calls getNext() on the RedeclLink of the canonical decl (which is supposed to point to the "most recent" declaration)</div><div> * RedeclLink queries its LazyGenerationalUpdatePtr, which calls CompleteRedeclChain on the ExternalASTSource if necessary to complete the redeclaration chain and obtain the definition</div><div><br></div><div>I guess that your ExternalASTSource supplies the type definition in response ExternalASTSource::CompleteType, not in response to ExternalASTSource::CompleteRedeclChain? I don't see how that mechanism is supposed to work -- it's only called when Sema wants a complete type, and not when any other part of the compiler is assuming that a type is complete.</div><div><br></div><div>Try adding the definition in CompleteRedeclChain instead, and see if that helps. If so, perhaps we should remove ExternalASTSource::CompleteType.</div></div></div></div>