Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Adrian McCarthy via lldb-dev
Thanks everyone. To close the loop, we've address this problem with this patch: http://reviews.llvm.org/rL250467 On Thu, Oct 15, 2015 at 11:49 AM, Zachary Turner wrote: > it doesn't appear to be a bug in my implementation. So it seems like > everyone has been experiencing this problem, but W

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Zachary Turner via lldb-dev
it doesn't appear to be a bug in my implementation. So it seems like everyone has been experiencing this problem, but Windows it just made a big difference because of the mandatory file locks. From the Python dcoumentation , This function returns a tup

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Nico Weber via lldb-dev
One possible approach is to never run a built executable directly, but to copy it to some other place (e.g. my-exe.exe -> my-exe-run-13.exe) and only run the copied executable. Then rebuilding the original won't fail. On Thu, Oct 15, 2015 at 9:10 AM, Oleksiy Vyalov via lldb-dev < lldb-dev@lists.ll

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Zachary Turner via lldb-dev
It's not that simple. A test method could be holding onto arbitrary resources which could in theory prevent cleanup. tests can register their own cleanup handlers for example, and the teardown will call back into the cleanup handler. So one of those handlers could be making the assumption that i

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Ryan Brown via lldb-dev
Couldn't we just change DeleteTarget to make sure everything is unmapped? On Thu, Oct 15, 2015 at 11:34 AM Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > To add more evidence for this, here's a small repro: > > import sys > > print "sys.exc_info() = ", "Empty" if sys.exc_info() =

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Zachary Turner via lldb-dev
To add more evidence for this, here's a small repro: import sys print "sys.exc_info() = ", "Empty" if sys.exc_info() == (None, None, None) else "Valid" try: raise Exception except Exception, e: print "sys.exc_info() = ", "Empty" if sys.exc_info() == (None, None, None) else "Valid" pas

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Zachary Turner via lldb-dev
We actually do already to the self.dbg.DeleteTarget(target), and that's the line that's failing. The reason it's failing is because the 'sc' reference is still alive, which is holding an mmap, which causes a mandatory file lock on Windows. The diagnostics went pretty deep into python internals, b

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Greg Clayton via lldb-dev
> On Oct 15, 2015, at 8:50 AM, Adrian McCarthy via lldb-dev > wrote: > > 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. > > Consider this portion of a test from TestTargetAPI: > > def fi

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Adrian McCarthy via lldb-dev
The gc.collect works only if I set the variables to None in the finally blocks, which is no better than just del'ing the objects in the finally blocks. On Thu, Oct 15, 2015 at 9:47 AM, Adrian McCarthy wrote: > > On Thu, Oct 15, 2015 at 9:31 AM, Todd Fiala wrote: > >> >> >> On Thu, Oct 15, 2015

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Adrian McCarthy via lldb-dev
On Thu, Oct 15, 2015 at 9:31 AM, Todd Fiala wrote: > > > On Thu, Oct 15, 2015 at 9:23 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> 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 sec

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Todd Fiala via lldb-dev
On Thu, Oct 15, 2015 at 9:23 AM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > 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.

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Todd Fiala via lldb-dev
On Thu, Oct 15, 2015 at 8:50 AM, Adrian McCarthy via lldb-dev < lldb-dev@lists.llvm.org> wrote: > 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. > > Consider this portion of a test from TestT

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Zachary Turner via lldb-dev
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 agai

Re: [lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Oleksiy Vyalov via lldb-dev
I stumbled upon similar problem when was looking into why SBDebugger wasn't unloaded upon app's exit. The problem was in Python global objects like lldb.debugger, lldb.target sitting around. So, my guess is to try to call ScriptInterpreterPython::Clear within test's tearDown call - e.g., expose Cl

[lldb-dev] Python object lifetimes affect the reliability of tests

2015-10-15 Thread Adrian McCarthy via lldb-dev
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. Consider this portion of a test from TestTargetAPI: def find_functions(self, exe_name): """Exercise SBTaget.FindFunctions() API."""