<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>I have spent more time than I would like to admit diagnosing a super weird and super hard to reproduce problem with clang that turned out to be yet another instance of the old "dangling pointer" problem.</div><div><br></div><div>This email is really meant just to outline the problem, not offer a solution - I am hoping that the clang experts on this list will offer the best solution.</div><div><br></div><div>So here's the problem...</div><div><br></div><div>When a <span style="font-family:monospace,monospace">Preprocessor</span> object is created by calling <span style="font-family:monospace,monospace">CompilerInstance::createPreprocessor(),</span> the existing shared pointer may already be pointing to an existing object. That existing object will own a <span style="font-family:monospace,monospace">HeaderSearch</span> which will own a <span style="font-family:monospace,monospace">ModuleMap</span> which will own a number of <span style="font-family:monospace,monospace">Module</span> objects. Pointers to those <span style="font-family:monospace,monospace">Module</span> objects may have been cached in the <span style="font-family:monospace,monospace">CompilerInstance::KnownModules</span> map by <span style="font-family:monospace,monospace">CompilerInstance::loadModule()</span>. However, creating the new <span style="font-family:monospace,monospace">Preprocessor</span> will make the shared pointer point to that new one and since there are no further references to the old one, it will be destroyed. Of course, everything the old <span style="font-family:monospace,monospace">Preprocessor</span> owns will be destroyed as well so we now have dangling pointers in the <span style="font-family:monospace,monospace">CompilerInstance::KnownModules</span> map.</div><div><br></div><div>As it turns out, it appears to be very difficult to end up in a situation where this is actually a problem. It seems to be related to the path of whatever this function is looking for. So with a very specific path for the build tree, we come across the problem with the last <span style="font-family:monospace,monospace">RUN</span> command in <span style="font-family:monospace,monospace">test/Modules/builtins.m</span>. Changing the build tree path by a single character seems to make the problem go away for some reason.</div><div><br></div><div>Now obviously, this problem can be fixed by just clearing <span style="font-family:monospace,monospace">CompilerInstance::KnownModules</span> if the shared pointer PP isn't null in <span style="font-family:monospace,monospace">CompilerInstance::createPreprocessor()</span>. However, I am not sure if that is the desired fix.</div><div><br></div><div>The attached patch isn't the fix I mentioned but a patch that can show the problem I have described. Applying that patch and running that test should cause the expected assert.</div><div><br></div><div>I would really appreciate feedback with regard to how best to fix this problem.<br></div></div></div></div></div>