[Lldb-commits] [PATCH] Add a --all command option to "target delete"

Zachary Turner zturner at google.com
Wed Mar 25 18:06:11 PDT 2015


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.

On Wed, Mar 25, 2015 at 5:52 PM <jingham at apple.com> wrote:

>
> > On Mar 25, 2015, at 5:18 PM, Zachary Turner <zturner at google.com> 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/
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20150326/eff1b818/attachment.html>


More information about the lldb-commits mailing list