> On Feb 21, 2017, at 4:26 PM, Greg Clayton <gclay...@apple.com> wrote: > >> >> On Feb 21, 2017, at 9:36 AM, Jim Ingham via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> >> Thanks for digging into this. >> >> Maybe a better option would be to have IRExecutionUnit hold a >> SymbolContextScope, rather than a SymbolContext. We started out with >> SymbolContext's because they were convenient but they hold too many things >> alive so when we run into SymbolContext's we've been converting them to the >> SymbolContextScope's when possible. I can't see any need for the >> IRExecutionUnit to hold the module alive, so long as it handles failure to >> get the SymbolContext gracefully, which shouldn't be hard. > > SymbolContextScope doesn't hold ownership as it is just a pointer. This > pointer would go bad if the module goes away and it would crash when you > tried to use it. See my other email for another approach with > SymbolContextRef.
Brain, brain, what is brain? Yeah, I was conflating ExecutionContextRef & SymbolContext<WORDS THAT ARE NOT REF>. But still, having a SymbolContext equivalent to ExecutionContextRef seems the correct solution to me, even though we don't have the pre-baked class for it. Jim > > Greg > >> >> Jim >> >>> On Feb 21, 2017, at 9:03 AM, Pavel Labath via lldb-dev >>> <lldb-dev@lists.llvm.org> wrote: >>> >>> Hello all, >>> >>> I've been debugging the newly added TestStepOverBreakpoint.py, which >>> has been failing on windows, for a very prosaic reason: after the test >>> completes, we are unable to run "make clean" because lldb still holds >>> the file open. >>> >>> After some debugging, I've found that this happens because the test >>> case stores the SBBreakpoint object in a member variable of the python >>> test case class. The breakpoint class ends up transitively holding a >>> reference to the main executable module, which prevents the module >>> from being garbage-collected when the target is destroyed. >>> >>> For reference, the full ownership chain is something like: >>> StepOverBreakpointTestCase(python) => SBBreakpoint => Breakpoint => >>> BreakpointLocation => LLVMUserExpression => IRExecutionUnit => >>> SymbolContext => Module. >>> >>> To get the test working, we need to break this chain somewhere. A >>> couple of places I see are: >>> - BreakpointLocation: Remove the compiled expression reference when >>> the target is destroyed (AFAICS, it is used as a cache to avoid >>> recomputing the expression every time. It can be theoretically >>> recomputed if needed, but that shouldn't be necessary as the target is >>> destroyed anyway) >>> >>> - SBBreakpoint: make SBBreakpoint hold a weak_ptr to the Breakpoint >>> object. When the target is destroyed, the SBBreakpoint object becomes >>> invalid (One doesn't cannot do anything useful with the breakpoint >>> once the target has been deleted anyway). >>> >>> - StepOverBreakpointTestCase: Have the test not store the breakpoints >>> in the test case object. Basically, declare that this is not a bug, >>> and it's the users responsibility to clean up necessary objects. >>> >>> Any thoughts on what is the appropriate solution here? >>> >>> cheers, >>> pavel >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
