> On Mar 25, 2015, at 6:06 PM, Zachary Turner <[email protected]> wrote: > > 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: > > def setup(self): > Base.setup(self) > > # Do TestBase specific stuff > > def tearDown(self): > Base.tearDown(self) > > # Do TestBase specific stuff > > 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. > > I fixed this by reversing the orders and also fixed about 20 other tests in > the process. Yay for progress.
Excellent! Jim > > On Wed, Mar 25, 2015 at 5:52 PM <[email protected]> wrote: > > > On Mar 25, 2015, at 5:18 PM, Zachary Turner <[email protected]> wrote: > > > > 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. > > 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? > 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. > > Jim > > > > > 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 : > > > > 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. > > > > Thoughts? > > > > > > http://reviews.llvm.org/D8615 > > > > EMAIL PREFERENCES > > http://reviews.llvm.org/settings/panel/emailpreferences/ > > > > > _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
