No comments on this specifically, but +1 to reducing shared_ptr usage in general.  We use way too many, and often it feels like shared_ptr is used as a way to avoid having to think about ownership, which leads to more problems than it solves imo<br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 21, 2017 at 9:03 AM Pavel Labath via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br class="gmail_msg">
<br class="gmail_msg">
I've been debugging the newly added TestStepOverBreakpoint.py, which<br class="gmail_msg">
has been failing on windows, for a very prosaic reason: after the test<br class="gmail_msg">
completes, we are unable to run "make clean" because lldb still holds<br class="gmail_msg">
the file open.<br class="gmail_msg">
<br class="gmail_msg">
After some debugging, I've found that this happens because the test<br class="gmail_msg">
case stores the SBBreakpoint object in a member variable of the python<br class="gmail_msg">
test case class. The breakpoint class ends up transitively holding a<br class="gmail_msg">
reference to the main executable module, which prevents the module<br class="gmail_msg">
from being garbage-collected when the target is destroyed.<br class="gmail_msg">
<br class="gmail_msg">
For reference, the full ownership chain is something like:<br class="gmail_msg">
StepOverBreakpointTestCase(python) => SBBreakpoint => Breakpoint =><br class="gmail_msg">
BreakpointLocation => LLVMUserExpression => IRExecutionUnit =><br class="gmail_msg">
SymbolContext => Module.<br class="gmail_msg">
<br class="gmail_msg">
To get the test working, we need to break this chain somewhere. A<br class="gmail_msg">
couple of places I see are:<br class="gmail_msg">
- BreakpointLocation: Remove the compiled expression reference when<br class="gmail_msg">
the target is destroyed (AFAICS, it is used as a cache to avoid<br class="gmail_msg">
recomputing the expression every time. It can be theoretically<br class="gmail_msg">
recomputed if needed, but that shouldn't be necessary as the target is<br class="gmail_msg">
destroyed anyway)<br class="gmail_msg">
<br class="gmail_msg">
- SBBreakpoint: make SBBreakpoint hold a weak_ptr to the Breakpoint<br class="gmail_msg">
object. When the target is destroyed, the SBBreakpoint object becomes<br class="gmail_msg">
invalid (One doesn't cannot do anything useful with the breakpoint<br class="gmail_msg">
once the target has been deleted anyway).<br class="gmail_msg">
<br class="gmail_msg">
- StepOverBreakpointTestCase: Have the test not store the breakpoints<br class="gmail_msg">
in the test case object. Basically, declare that this is not a bug,<br class="gmail_msg">
and it's the users responsibility to clean up necessary objects.<br class="gmail_msg">
<br class="gmail_msg">
Any thoughts on what is the appropriate solution here?<br class="gmail_msg">
<br class="gmail_msg">
cheers,<br class="gmail_msg">
pavel<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
lldb-dev mailing list<br class="gmail_msg">
<a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a><br class="gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class="gmail_msg">
</blockquote></div>