Re: [lldb-dev] LLDB tests duplicated between lldb-suite and lit

+1 for removing. I've been wanting to do that for a while now... >> >> Looking at the other duplicated tests, we have the potential for similar >> issues. They also all use CHECK rather then CHECK-DAG, so we should at least >> update them to use CHECK-DAG. Could you elaborate on this? I don't s

Re: [lldb-dev] LLDB tests duplicated between lldb-suite and lit

Yea, removing them is probably fine. On Tue, Jul 17, 2018 at 11:14 AM Stella Stamenova wrote: > Hey all, > > > > I’ve been looking at some of the test failures on Windows and this led me > to realize that there are at least several tests that are duplicated > between lldb-suite and the lit tests

[lldb-dev] LLDB tests duplicated between lldb-suite and lit

Hey all, I've been looking at some of the test failures on Windows and this led me to realize that there are at least several tests that are duplicated between lldb-suite and the lit tests. This appears to have been on purpose circa 2016 as a proof of concept for moving tests from lldb-suite to

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

Great, thanks Pavel! On Wed, May 2, 2018 at 10:06 AM, Pavel Labath wrote: > Ok, r331374 ought to fix that. The situation was a bit more complicated > then I thought, because the function was behaving differently if one builds > lldb with xml support, so i've had to update the test to work correc

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

Ok, r331374 ought to fix that. The situation was a bit more complicated then I thought, because the function was behaving differently if one builds lldb with xml support, so i've had to update the test to work correctly in both situations. On Wed, 2 May 2018 at 16:34, Pavel Labath wrote: > Right,

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

Right, I see what's going on now. Yes, you're right, the commit you mention has added extra packets which are not handled in the mock. The reason this is hanging for you is because you are using a debug build, which has a much larger packet timeout (1000s i think). In the release build this passes,

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

PS. just a wild guess, could it be related to : rL327970: Re-land: [lldb] Use vFlash commands when writing to target's flash memory… ? On Tue, May 1, 2018 at 1:24 PM, Leonard Mosescu wrote: > Thanks Pavel. It doesn't look like a timeout to me: > > 1. First, the other (main) thread is just waitin

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

Thanks Pavel. It doesn't look like a timeout to me: 1. First, the other (main) thread is just waiting on the std::future::get() on the final EXPECT_TRUE(result.get().Success()) *#0 0x7fe4bdfbb6cd in pthread_join (threadid=140620333614848, thread_return=0x0) at pthread_join.c:90* *...* *#14 0

Re: [lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

On Thu, 26 Apr 2018 at 22:58, Leonard Mosescu via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I just did a clean build (debug) on Linux, and I noticed that the LLDB tests seem to consistently get stuck: > -- Testing: 1002 tests, 12 th

[lldb-dev] LLDB tests getting stuck on GDBRemoteCommunicationClientTest.GetMemoryRegionInfo ?

I just did a clean build (debug) on Linux, and I noticed that the LLDB tests seem to consistently get stuck: * -- Testing: 1002 tests, 12 threads -- * * 99% [

[lldb-dev] LLDB tests unable to find 'lldb-mi' on Windows

Hi, I been trying to run the LLDB test suite on Windows (check-lldb). The LLDB used was build with VS2015 and ninja. When I try to run an specific test, using the commands: cd D:\LLVM\llvm\tools\lldb\test python dotest.py --executable "D:\LLVM\build-ninja-lldb\bin\lldb.exe" -p TestInlineSteppin

Re: [lldb-dev] LLDB tests

> On Jul 24, 2017, at 10:48 AM, Sean Callanan via lldb-dev > wrote: > > Steve, > > since you asked about failures, here are some public bots you can look at to > get a general sense of how we are doing: > > http://lab.llvm.org:8011/builders > [various pla

Re: [lldb-dev] LLDB tests

> On Jul 24, 2017, at 3:03 AM, Steve Trotter via lldb-dev > wrote: > > Hi all, > > I'm fairly new to LLVM and LLDB, I became interested in this project about 3 > months back and I'm hoping to be able to contribute to improving LLDB in > time. I've been trying to get to grips with the code an

Re: [lldb-dev] LLDB tests

Steve, since you asked about failures, here are some public bots you can look at to get a general sense of how we are doing: * http://lab.llvm.org:8011/builders [various platforms] * http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/ [OS X] * https://ci.swift.org/view/All/job/oss

[lldb-dev] LLDB tests

Hi all, I'm fairly new to LLVM and LLDB, I became interested in this project about 3 months back and I'm hoping to be able to contribute to improving LLDB in time. I've been trying to get to grips with the code and have been looking into the tests as a rough guide to how things work, however I hav

Re: [lldb-dev] lldb tests and tear down hooks

There's no reason a finally block inside each test method wouldn't work, and that's probably the simplest solution. On Fri, Jan 15, 2016 at 12:59 AM Pavel Labath wrote: > On 14 January 2016 at 21:52, Zachary Turner via lldb-dev > wrote: > > So what if tests could be *either* a method *or* a nes

Re: [lldb-dev] lldb tests and tear down hooks

On 14 January 2016 at 21:52, Zachary Turner via lldb-dev wrote: > So what if tests could be *either* a method *or* a nested class. If it's a > nested class, it could provide setUp, tearDown, and run methods. These > setup and teardown methods can do whatever they want specific to the > individua

Re: [lldb-dev] lldb tests and tear down hooks

So this is biting us again, for unrelated reasons. I thought of a potentially interesting solution. Right now each test class has a setUp and tearDown method. This method is called before and after EVERY test method in the class. So you can't put anything in these methods unless it's common to

Re: [lldb-dev] lldb tests and tear down hooks

(And side note: if you're pushing a "lambda: self.foo()" with no arguments, the lambda is unneeded and you can just push "self.foo" --- that cleanup hook pushed on most tests at the end of the file is a perfect example of an unneeded level of lambda indirection). On Wed, Oct 21, 2015 at 12:04 PM,

Re: [lldb-dev] lldb tests and tear down hooks

Well you can see them getting added via self.addTearDownHook(), so that means they're called through an instance. Specifically, it happens in Base.tearDown(self), so it's basically identical (in concept) to if the relevant handlers were called in the implementation of MyTest.tearDown(), but differ

Re: [lldb-dev] lldb tests and tear down hooks

I think it was mostly done to provide an exception safe way to cleanup stuff without having to override TestBase.tearDown(). I am guessing this cleanup happens on TestCase.tearDown() and not after the current test case right? I could see it being used to cleanup after a single test case in case

Re: [lldb-dev] lldb tests and tear down hooks

Yea, that's what I think too. I think this mechanism was probably invented to just to save some code and promote reusability, but in practice leads to these kinds of problems. On Wed, Oct 21, 2015 at 2:07 AM Pavel Labath wrote: > I think we can remove these, provided there is a way to mimic the

Re: [lldb-dev] lldb tests and tear down hooks

I think we can remove these, provided there is a way to mimic the functionality they are used for now, which I think shouldn't be hard. Anything which was set up in the setUp() method should be undone in tearDown(). Anything which was set up in the test method, can be undone using a try-finally blo

[lldb-dev] lldb tests and tear down hooks

There's a subtle bug that is pervasive throughout the test suite. Consider the following seemingly innocent test class. class MyTest(TestBase); def setUp(): TestBase.setUp()#1 # Do some stuff #2 self.addTearDownHook(lambda: self.foo()) #3 def test_inte