<div dir="ltr">Ironically even though I've been staring at this problem for 2 days I think I actually figured this out shortly after my last email.  TestBase.tearDown() already deletes all the targets but it was calling Base.tearDown before doing TestBase.tearDown().  So the setup looked like this:<br><div><br></div><div>def setup(self):</div><div>    Base.setup(self)</div><div><br></div><div>    # Do TestBase specific stuff</div><div><br></div><div>def tearDown(self):</div><div>    Base.tearDown(self)</div><div><br></div><div>    # Do TestBase specific stuff</div><div><br></div><div>the orders here need to be reversed to ensure that teardown happens in reverse order from setup.  In particular Base.tearDown() was calling the tear down hooks, one of which in this case was to call make clean.  So make clean was being called before the targets were deleted.  My clean --all helped, but as you said, the SB stuff was still holding a reference somewhere.</div><div><br></div><div>I fixed this by reversing the orders and also fixed about 20 other tests in the process.  Yay for progress.</div></div><br><div class="gmail_quote">On Wed, Mar 25, 2015 at 5:52 PM <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Mar 25, 2015, at 5:18 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> Seems reasonable, I can add something to the help.  What do you think about also changing the semantics of --clean to clear the module list regardless of if the modules are orphaned?  I've spent the past 2 days trying to track down a refcounting bug related to the shared module list that only happens when running from the test suite, even if I run the exact same sequence of commands from inside LLDB.  But the gist of it is that when running from the test suite, when RemoveOrphanSharedModules() is called from the CommandObject, the ModuleSP for the executable has a ref count of 2, so it isn't unique to the shared module list, and it doesn't get removed.<br>
<br>
This makes it sound like some Python object that is holding onto a reference to the executable isn't getting garbage collected.  Is there some way to force Python to do this?<br>
It seem to me like violating the function of the shared cache, particularly from the lldb command line, is not a great idea.  Even --clean seems a little unfortunate to have in the command line, since some innocent person will run the help command and then be worried about what this whole clean thing is and whether it is a good idea and etc.  Might be better, if this is necessary, to have it only in the SB API where we can put an appropriate comment around it.  That way ordinary users who should 100% never have to think about this won't be disturbed by it.<br>
<br>
Jim<br>
<br>
><br>
> I tested to see what happens if I change this logic to remove from the module list regardless of whether it's unique, and I can't find any unintended side effects other than lots of tests start passing :<br>
><br>
> shared_ptrs are shared, so in theory there shouldn't be any negative consequences to just removing it.  Whoever still has a reference can still continue to use it.  Alternatively I can add a --force command line option, so that the semantics of specifying just --clean are unchanged.<br>
><br>
> Thoughts?<br>
><br>
><br>
> <a href="http://reviews.llvm.org/D8615" target="_blank">http://reviews.llvm.org/D8615</a><br>
><br>
> EMAIL PREFERENCES<br>
>  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/<u></u>settings/panel/<u></u>emailpreferences/</a><br>
><br>
><br>
<br>
</blockquote></div>