<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 15, 2015 at 9:23 AM, Zachary Turner via lldb-dev <span dir="ltr"><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">That wouldn't work in this case because it causes a failure from one test to the next. So a single test suite has 5 tests, and the second one fails because the first one didn't clean up correctly. You couldn't call ScriptInterpreterpython::Clear here, because then you'd have to initialize it again, and while it might work, it seems scary and like something which is untested and we recommend you don't do.<div><br></div><div>What about calling `gc.collect()` in the tearDown() method?</div></div></blockquote><div><br></div><div>If it's a laziness thing, that seems like it might do it. I would think we could stick that in the base test class and get it everywhere. Is that something you can try, Adrian?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 15, 2015 at 9:10 AM Oleksiy Vyalov via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">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"><div dir="ltr">I stumbled upon similar problem when was looking into why SBDebugger wasn't unloaded upon app's exit.<div>The problem was in Python global objects like lldb.debugger, lldb.target sitting around.</div><div>So, my guess is to try to call ScriptInterpreterPython::Clear within test's tearDown call - e.g., expose Clear method as part of SBCommandInterpreter and call it via SBDebugger::GetCommandInterpreter</div></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 15, 2015 at 8:50 AM, Adrian McCarthy via lldb-dev <span dir="ltr"><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I've tracked down a source of flakiness in tests on Windows to Python object lifetimes and the SB interface, and I'm wondering how best to handle it.</div><div><br></div><div>Consider this portion of a test from TestTargetAPI:</div><div><br></div><div><font face="monospace, monospace" size="1"> def find_functions(self, exe_name):</font></div><div><font face="monospace, monospace" size="1"> """Exercise SBTaget.FindFunctions() API."""</font></div><div><font face="monospace, monospace" size="1"> exe = os.path.join(os.getcwd(), exe_name)</font></div><div><font face="monospace, monospace" size="1"><br></font></div><div><font face="monospace, monospace" size="1"> # Create a target by the debugger.</font></div><div><font face="monospace, monospace" size="1"> target = self.dbg.CreateTarget(exe)</font></div><div><font face="monospace, monospace" size="1"> self.assertTrue(target, VALID_TARGET)</font></div><div><font face="monospace, monospace" size="1"> list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)</font></div><div><font face="monospace, monospace" size="1"> self.assertTrue(list.GetSize() == 1)</font></div><div><font face="monospace, monospace" size="1"><br></font></div><div><font face="monospace, monospace" size="1"> for sc in list:</font></div><div><font face="monospace, monospace" size="1"> self.assertTrue(sc.GetModule().GetFileSpec().GetFilename() == exe_name)</font></div><div><font face="monospace, monospace" size="1"> self.assertTrue(sc.GetSymbol().GetName() == 'c')</font></div><div><br></div><div>The local variables go out of scope when the function exits, but the SB (C++) objects they represent aren't (always) immediately destroyed. At least some of these objects keep references to the executable module in the shared module list, so when the test framework cleans up and calls `SBDebugger::DeleteTarget`, the module isn't orphaned, so LLDB maintains an open handle to the executable.</div><div><br></div><div>The result of the lingering handle is that, when the next test case in the test suite tries to re-build the executable, it fails because the file is not writable. (This is problematic on Windows because the file system works differently in this regard than Unix derivatives.) Every subsequent case in the test suite fails.</div><div><br></div><div>I managed to make the test work reliably by rewriting it like this:</div><div><br></div><div><font size="1" face="monospace, monospace"> def find_functions(self, exe_name):</font></div><div><font size="1" face="monospace, monospace"> """Exercise SBTaget.FindFunctions() API."""</font></div><div><font size="1" face="monospace, monospace"> exe = os.path.join(os.getcwd(), exe_name)</font></div><div><font size="1" face="monospace, monospace"><br></font></div><div><font size="1" face="monospace, monospace"> # Create a target by the debugger.</font></div><div><font size="1" face="monospace, monospace"> target = self.dbg.CreateTarget(exe)</font></div><div><font size="1" face="monospace, monospace"> self.assertTrue(target, VALID_TARGET)</font></div><div><font size="1" face="monospace, monospace"><br></font></div><div><font size="1" face="monospace, monospace"> try:</font></div><div><font size="1" face="monospace, monospace"> list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)</font></div><div><font size="1" face="monospace, monospace"> self.assertTrue(list.GetSize() == 1)</font></div><div><font size="1" face="monospace, monospace"><br></font></div><div><font size="1" face="monospace, monospace"> for sc in list:</font></div><div><font size="1" face="monospace, monospace"> try:</font></div><div><font size="1" face="monospace, monospace"> self.assertTrue(sc.GetModule().GetFileSpec().GetFilename() == exe_name)</font></div><div><font size="1" face="monospace, monospace"> self.assertTrue(sc.GetSymbol().GetName() == 'c')</font></div><div><font size="1" face="monospace, monospace"> finally:</font></div><div><font size="1" face="monospace, monospace"> del sc</font></div><div><font size="1" face="monospace, monospace"><br></font></div><div><font size="1" face="monospace, monospace"> finally:</font></div><div><font size="1" face="monospace, monospace"> del list</font></div><div><br></div><div>The finally blocks ensure that the corresponding C++ objects are destroyed, even if the function exits as a result of a Python exception (e.g., if one of the assertion expressions is false and the code throws an exception). Since the objects are destroyed, the reference counts are back to where they should be, and the orphaned module is closed when the target is deleted.</div><div><br></div><div>But this is ugly and maintaining it would be error prone. Is there a better way to address this?</div><div><br></div><div>In general, it seems bad that our tests aren't well-isolated. I sympathize with the concern that re-starting LLDB for each test case would slow down testing, but I'm also concerned that the state of LLDB for any given test case can depend on what happened in the earlier cases.</div><span><font color="#888888"><div><br></div><div>Adrian.</div></font></span></div>
<br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div><div class="gmail_extra">-- <br><div><div dir="ltr"><span style="color:rgb(85,85,85);font-family:sans-serif;line-height:20px;background-color:rgb(255,255,255);border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Oleksiy Vyalov |</span><span style="color:rgb(85,85,85);font-family:sans-serif;line-height:20px;background-color:rgb(255,255,255);border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Software Engineer |</span><span style="color:rgb(85,85,85);font-family:sans-serif;line-height:20px;background-color:rgb(255,255,255);border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> <a href="mailto:ovyalov@google.com" target="_blank">ovyalov<font color="#1155cc">@google.com</font></a></span></div></div>
</div>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div></div>