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

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

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

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

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

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

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

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

> 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

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

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

[lldb-dev] [Bug 25194] New: LLDB-Server Assertion raised when single stepping on MIPS

https://llvm.org/bugs/show_bug.cgi?id=25194 Bug ID: 25194 Summary: LLDB-Server Assertion raised when single stepping on MIPS Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW

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

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

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

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] Question on assert

This seems to be working. I put it up for review here, Tamas: http://reviews.llvm.org/D13777 On Thu, Oct 15, 2015 at 9:03 AM, Todd Fiala wrote: > I'm re-running the tests to make sure, but I think that fixed it. I had > always seen it at least once on test runs locally, but didn't see it on t

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

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

Re: [lldb-dev] Question on assert

I'm re-running the tests to make sure, but I think that fixed it. I had always seen it at least once on test runs locally, but didn't see it on the last one. On Thu, Oct 15, 2015 at 8:10 AM, Todd Fiala wrote: > Okay! I'll give that a shot now and report back what I find. > > Thanks, Tamas :-)

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

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."""

Re: [lldb-dev] Question on assert

Okay! I'll give that a shot now and report back what I find. Thanks, Tamas :-) -Todd On Thu, Oct 15, 2015 at 3:37 AM, Tamas Berghammer wrote: > Hi Todd, > > The 64 bit ID of a DIE is built up in the following way: > * The offset of the DIE is in the lower 32 bit > * If we are using SymbolFile

Re: [lldb-dev] Question on assert

Hi Todd, The 64 bit ID of a DIE is built up in the following way: * The offset of the DIE is in the lower 32 bit * If we are using SymbolFileDWARF then the higher 32 bit is the offset of the compile unit this DIE belongs to * If we are using SymbolFileDWARFDwo then the higher 32 bit is the offset

Re: [lldb-dev] LLDB: Unwinding based on Assembly Instruction Profiling

If we are trying to unwind from a non call site (frame 0 or signal handler) then the current implementation first try to use the non call site unwind plan (usually assembly emulation) and if that one fails then it will fall back to the call site unwind plan (eh_frame, compact unwind info, etc.) ins