Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

[Tamas Berghammer via lldb-dev]

One more point to Zachary's comment is that currently if LLDB crashes for a
test we report the test failure somewhat correctly (not perfectly). With a
multi threaded approach I would expect an LLDB crash to take down the full
test run what isn't something we want.

On Tue, Sep 22, 2015 at 12:03 AM Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> After our last discussion, I thought about it some more and there are at
> least some problems with this.  The biggest problem is that with only a
> single process, you are doing all tests from effectively a single instance
> of LLDB.  There's a TestMultipleDebuggers.py for example, and whether or
> not that test passes is equivalent to whether or not the test suite can
> even work without dying horribly.  In other words, you are inherently
> relying on multiple debuggers working to even run the test suite.
>
> I don't know if that's a problem, but at the very least, it's kind of
> unfortunate.  And of course the problem grows to other areas.  What other
> things fail horribly when a single instance of LLDB is debugging 100
> processes at the same time?
>
> It's worth adding this as an alternate run mode, but I don't think we
> should make it default until it's more battle-tested.
>
> On Mon, Sep 21, 2015 at 12:49 PM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I'm considering changing the default lldb test runner from
>> multiprocessing-based to threading-based.  Long ago I switched it from
>> threading to multiprocessing.  The only reason I did this was because OS X
>> was failing to allow more than one exec at a time in the worker threads -
>> way down in the Python Global Interpreter Lock (GIL).  And, at the time, I
>> didn't have the time to break out the test runner strategies.
>>
>> We have verified the threading-based issue is no longer manifesting on OS
>> X 10.10 and 10.11 beta.  That being the case, I'd like to convert us back
>> to being threading-based by default.  Specifically, this will have the same
>> effect as doing the following:
>> (non-Windows): --test-runner-name threading
>> (Windows): --test-runner-name threading-pool
>>
>> There are a couple benefits here:
>> 1. We'll remove a fork for creating the worker queues.  Each of those are
>> just threads when using threading, rather than being forked processes.
>> Depending on the underlying OS, a thread is typically cheaper.  Also, some
>> of the inter-worker communication now becomes cheap intra-process
>> communication instead of heavier multiprocessing constructs.
>> 2. Debugging is a bit easier.  The worker queues make a lot of noise in
>> 'ps aux'-style greps, and are a pain to debug relatively speaking vs. the
>> threaded version.
>>
>> I'm not yet looking to remove the multiprocessing support.  It is likely
>> I'll check the OS X version and default to the multiprocessing test runner
>> if it wasn't explicitly specified and the OS X version is < 10.10 as I'm
>> pretty sure I hit the issue on 10.9's python.
>>
>> Thoughts?
>> --
>> -Todd
>> ___
>> 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

[lldb-dev] [Bug 21620] SB API GetValueDidChange() returns false although value did change, on FreeBSD

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=21620

ema...@freebsd.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from ema...@freebsd.org ---
Decorator removed in r248269

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Diffusion] rL248282: test runner: Unix systems now put inferior dotest in its own process group.

[Todd Fiala via lldb-dev]

Hey Zachary,

There is a Windows-specific subprocess.CREATE_NEW_PROCESS_GROUP flag that
you could potentially add to the Windows branch of the suprocess creation
call in dosep.py.  I'm not sure how useful that is on the Windows end as
this is mostly about console signal isolation, but I thought I'd call it
out in case you were interested in adding that to the Windows inferior
dotest.py creation.

-Todd

On Tue, Sep 22, 2015 at 8:23 AM, Todd Fiala  wrote:

> tfiala committed rL248282: test runner: Unix systems now put inferior
> dotest in its own process group..
>
> test runner: Unix systems now put inferior dotest in its own process group.
>
> This increases isolation as it relates to signal handling between parent
> and
> children.
>
>
> Files:
>   /lldb/trunk/test/dosep.py
>
> Users:
>   tfiala (Author)
>
> http://reviews.llvm.org/rL248282
>
>
>
>


-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

[Todd Fiala via lldb-dev]

Hey guys,

I think you're misunderstanding the process structure here.

The threading-based parallel test runner still execs out to a child
*process* for the inferio dotest.py run.  So suggesting we move to
threading is not going to put all tests in a single LLDB process.  We will
always want to be testing lldb with process isolation per dotest.py
inferior call.

The multiprocessing-based parallel test runner really has an extra layer of
process involved.  Each worker is a separate process (per the
multiprocessing model), which then execs a child process which is
dotest.py.  So every inferior dotest.py has a process (the inferior
dotest.py process) and the multiprocess-based worker process.  With the
threading-based test runner, every dotest.py inferior test process is its
own isolated process, and it's driven by a test runner thread in the main
dotest.py process.

We are not changing anything about the semantics of the test execution
itself when we do this, nor do we impact the reporting in any way.  It's
purely a test running infrastructural change that happens to be more
efficient on most OSes due to the lighter weight of the a thread in most
places vs. a full-blown process.

On Tue, Sep 22, 2015 at 2:32 AM, Tamas Berghammer 
wrote:

> One more point to Zachary's comment is that currently if LLDB crashes for
> a test we report the test failure somewhat correctly (not perfectly). With
> a multi threaded approach I would expect an LLDB crash to take down the
> full test run what isn't something we want.
>
> On Tue, Sep 22, 2015 at 12:03 AM Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> After our last discussion, I thought about it some more and there are at
>> least some problems with this.  The biggest problem is that with only a
>> single process, you are doing all tests from effectively a single instance
>> of LLDB.  There's a TestMultipleDebuggers.py for example, and whether or
>> not that test passes is equivalent to whether or not the test suite can
>> even work without dying horribly.  In other words, you are inherently
>> relying on multiple debuggers working to even run the test suite.
>>
>> I don't know if that's a problem, but at the very least, it's kind of
>> unfortunate.  And of course the problem grows to other areas.  What other
>> things fail horribly when a single instance of LLDB is debugging 100
>> processes at the same time?
>>
>> It's worth adding this as an alternate run mode, but I don't think we
>> should make it default until it's more battle-tested.
>>
>> On Mon, Sep 21, 2015 at 12:49 PM Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi all,
>>>
>>> I'm considering changing the default lldb test runner from
>>> multiprocessing-based to threading-based.  Long ago I switched it from
>>> threading to multiprocessing.  The only reason I did this was because OS X
>>> was failing to allow more than one exec at a time in the worker threads -
>>> way down in the Python Global Interpreter Lock (GIL).  And, at the time, I
>>> didn't have the time to break out the test runner strategies.
>>>
>>> We have verified the threading-based issue is no longer manifesting on
>>> OS X 10.10 and 10.11 beta.  That being the case, I'd like to convert us
>>> back to being threading-based by default.  Specifically, this will have the
>>> same effect as doing the following:
>>> (non-Windows): --test-runner-name threading
>>> (Windows): --test-runner-name threading-pool
>>>
>>> There are a couple benefits here:
>>> 1. We'll remove a fork for creating the worker queues.  Each of those
>>> are just threads when using threading, rather than being forked processes.
>>> Depending on the underlying OS, a thread is typically cheaper.  Also, some
>>> of the inter-worker communication now becomes cheap intra-process
>>> communication instead of heavier multiprocessing constructs.
>>> 2. Debugging is a bit easier.  The worker queues make a lot of noise in
>>> 'ps aux'-style greps, and are a pain to debug relatively speaking vs. the
>>> threaded version.
>>>
>>> I'm not yet looking to remove the multiprocessing support.  It is likely
>>> I'll check the OS X version and default to the multiprocessing test runner
>>> if it wasn't explicitly specified and the OS X version is < 10.10 as I'm
>>> pretty sure I hit the issue on 10.9's python.
>>>
>>> Thoughts?
>>> --
>>> -Todd
>>> ___
>>> 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
>>
>


-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

[Todd Fiala via lldb-dev]

On Tue, Sep 22, 2015 at 8:49 AM, Todd Fiala  wrote:

> Hey guys,
>
> I think you're misunderstanding the process structure here.
>
> The threading-based parallel test runner still execs out to a child
> *process* for the inferio dotest.py run.  So suggesting we move to
> threading is not going to put all tests in a single LLDB process.  We will
> always want to be testing lldb with process isolation per dotest.py
> inferior call.
>
> The multiprocessing-based parallel test runner really has an extra layer
> of process involved.  Each worker is a separate process (per the
> multiprocessing model), which then execs a child process which is
> dotest.py.
>

I'm being fast and loose with "execs" in the sentence above.  It creates a
child process (not execs into it) from the multiprocessing worker process.
The same worker multiprocessing process hangs around and services all items
for that worker queue.  That process is the extra bloat we get rid of and
convert to a thread in the threading model.  That also allows us to use
lighter primitives for main-test-runner / worker communication, which no
longer need one or more processes just to manage communication between them
(implementation details of multiprocessing.Queue and
multiprocessing.Manager, for example).


> So every inferior dotest.py has a process (the inferior dotest.py process)
> and the multiprocess-based worker process.  With the threading-based test
> runner, every dotest.py inferior test process is its own isolated process,
> and it's driven by a test runner thread in the main dotest.py process.
>
> We are not changing anything about the semantics of the test execution
> itself when we do this, nor do we impact the reporting in any way.  It's
> purely a test running infrastructural change that happens to be more
> efficient on most OSes due to the lighter weight of the a thread in most
> places vs. a full-blown process.
>
> On Tue, Sep 22, 2015 at 2:32 AM, Tamas Berghammer 
> wrote:
>
>> One more point to Zachary's comment is that currently if LLDB crashes for
>> a test we report the test failure somewhat correctly (not perfectly). With
>> a multi threaded approach I would expect an LLDB crash to take down the
>> full test run what isn't something we want.
>>
>> On Tue, Sep 22, 2015 at 12:03 AM Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> After our last discussion, I thought about it some more and there are at
>>> least some problems with this.  The biggest problem is that with only a
>>> single process, you are doing all tests from effectively a single instance
>>> of LLDB.  There's a TestMultipleDebuggers.py for example, and whether or
>>> not that test passes is equivalent to whether or not the test suite can
>>> even work without dying horribly.  In other words, you are inherently
>>> relying on multiple debuggers working to even run the test suite.
>>>
>>> I don't know if that's a problem, but at the very least, it's kind of
>>> unfortunate.  And of course the problem grows to other areas.  What other
>>> things fail horribly when a single instance of LLDB is debugging 100
>>> processes at the same time?
>>>
>>> It's worth adding this as an alternate run mode, but I don't think we
>>> should make it default until it's more battle-tested.
>>>
>>> On Mon, Sep 21, 2015 at 12:49 PM Todd Fiala via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 Hi all,

 I'm considering changing the default lldb test runner from
 multiprocessing-based to threading-based.  Long ago I switched it from
 threading to multiprocessing.  The only reason I did this was because OS X
 was failing to allow more than one exec at a time in the worker threads -
 way down in the Python Global Interpreter Lock (GIL).  And, at the time, I
 didn't have the time to break out the test runner strategies.

 We have verified the threading-based issue is no longer manifesting on
 OS X 10.10 and 10.11 beta.  That being the case, I'd like to convert us
 back to being threading-based by default.  Specifically, this will have the
 same effect as doing the following:
 (non-Windows): --test-runner-name threading
 (Windows): --test-runner-name threading-pool

 There are a couple benefits here:
 1. We'll remove a fork for creating the worker queues.  Each of those
 are just threads when using threading, rather than being forked processes.
 Depending on the underlying OS, a thread is typically cheaper.  Also, some
 of the inter-worker communication now becomes cheap intra-process
 communication instead of heavier multiprocessing constructs.
 2. Debugging is a bit easier.  The worker queues make a lot of noise in
 'ps aux'-style greps, and are a pain to debug relatively speaking vs. the
 threaded version.

 I'm not yet looking to remove the multiprocessing support.  It is
 likely I'll check the OS X version and default to the multiprocessing test
 runner

Re: [lldb-dev] I see at least one test hanging...

[Todd Fiala via lldb-dev]

I stopped the two builds in progress (that were badly hanging, 20 minutes
per test run configuration) until the builder caught up to r248284.

-Todd

On Tue, Sep 22, 2015 at 9:06 AM, Todd Fiala  wrote:

> Rolled back here:
> ➜  lldb  svn commit
> Sendingtest/dosep.py
> Transmitting file data .
> Committed revision 248284.
>
> I'll re-add this and limit to OS X after I get a chance to review.
>
> -Todd
>
> On Tue, Sep 22, 2015 at 9:01 AM, Todd Fiala  wrote:
>
>> Hey all,
>>
>> On the Linux build bot, I'm seeing at least one test hung here after my
>> change:
>>
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/6572
>>
>> It is conceivable that my change to put the test inferior into a separate
>> process group is interfering with timeout handling.
>>
>> I'll revert that out and only add it in for OS X where we're primarily
>> seeing the hangup issue.  If that addresses the hangs, then I'll need to
>> investigate further.
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] I see at least one test hanging...

[Todd Fiala via lldb-dev]

I suspect my issue may have been over-isolation.  While I only needed a new
process group, I did it by creating a new session.  The SIGQUIT used by
timeout/gtimeout may not be able to work across sessions.

I'm going to give this another try with just setting the process group
without creating a new session.  I'll watch that one as well as it goes
through the bot.

-Todd

On Tue, Sep 22, 2015 at 9:09 AM, Todd Fiala  wrote:

> I stopped the two builds in progress (that were badly hanging, 20 minutes
> per test run configuration) until the builder caught up to r248284.
>
> -Todd
>
> On Tue, Sep 22, 2015 at 9:06 AM, Todd Fiala  wrote:
>
>> Rolled back here:
>> ➜  lldb  svn commit
>> Sendingtest/dosep.py
>> Transmitting file data .
>> Committed revision 248284.
>>
>> I'll re-add this and limit to OS X after I get a chance to review.
>>
>> -Todd
>>
>> On Tue, Sep 22, 2015 at 9:01 AM, Todd Fiala  wrote:
>>
>>> Hey all,
>>>
>>> On the Linux build bot, I'm seeing at least one test hung here after my
>>> change:
>>>
>>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/6572
>>>
>>> It is conceivable that my change to put the test inferior into a
>>> separate process group is interfering with timeout handling.
>>>
>>> I'll revert that out and only add it in for OS X where we're primarily
>>> seeing the hangup issue.  If that addresses the hangs, then I'll need to
>>> investigate further.
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] I see at least one test hanging...

[Todd Fiala via lldb-dev]

Hey all,

On the Linux build bot, I'm seeing at least one test hung here after my
change:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/6572

It is conceivable that my change to put the test inferior into a separate
process group is interfering with timeout handling.

I'll revert that out and only add it in for OS X where we're primarily
seeing the hangup issue.  If that addresses the hangs, then I'll need to
investigate further.

-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] I see at least one test hanging...

[Todd Fiala via lldb-dev]

Rolled back here:
➜  lldb  svn commit
Sendingtest/dosep.py
Transmitting file data .
Committed revision 248284.

I'll re-add this and limit to OS X after I get a chance to review.

-Todd

On Tue, Sep 22, 2015 at 9:01 AM, Todd Fiala  wrote:

> Hey all,
>
> On the Linux build bot, I'm seeing at least one test hung here after my
> change:
>
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/6572
>
> It is conceivable that my change to put the test inferior into a separate
> process group is interfering with timeout handling.
>
> I'll revert that out and only add it in for OS X where we're primarily
> seeing the hangup issue.  If that addresses the hangs, then I'll need to
> investigate further.
>
> --
> -Todd
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

[Zachary Turner via lldb-dev]

Ahh right, of course.  Disregard my comment then, I forgot about that extra
layer

On Tue, Sep 22, 2015 at 8:53 AM Todd Fiala  wrote:

> On Tue, Sep 22, 2015 at 8:49 AM, Todd Fiala  wrote:
>
>> Hey guys,
>>
>> I think you're misunderstanding the process structure here.
>>
>> The threading-based parallel test runner still execs out to a child
>> *process* for the inferio dotest.py run.  So suggesting we move to
>> threading is not going to put all tests in a single LLDB process.  We will
>> always want to be testing lldb with process isolation per dotest.py
>> inferior call.
>>
>> The multiprocessing-based parallel test runner really has an extra layer
>> of process involved.  Each worker is a separate process (per the
>> multiprocessing model), which then execs a child process which is
>> dotest.py.
>>
>
> I'm being fast and loose with "execs" in the sentence above.  It creates a
> child process (not execs into it) from the multiprocessing worker process.
> The same worker multiprocessing process hangs around and services all items
> for that worker queue.  That process is the extra bloat we get rid of and
> convert to a thread in the threading model.  That also allows us to use
> lighter primitives for main-test-runner / worker communication, which no
> longer need one or more processes just to manage communication between them
> (implementation details of multiprocessing.Queue and
> multiprocessing.Manager, for example).
>
>
>> So every inferior dotest.py has a process (the inferior dotest.py
>> process) and the multiprocess-based worker process.  With the
>> threading-based test runner, every dotest.py inferior test process is its
>> own isolated process, and it's driven by a test runner thread in the main
>> dotest.py process.
>>
>> We are not changing anything about the semantics of the test execution
>> itself when we do this, nor do we impact the reporting in any way.  It's
>> purely a test running infrastructural change that happens to be more
>> efficient on most OSes due to the lighter weight of the a thread in most
>> places vs. a full-blown process.
>>
>> On Tue, Sep 22, 2015 at 2:32 AM, Tamas Berghammer > > wrote:
>>
>>> One more point to Zachary's comment is that currently if LLDB crashes
>>> for a test we report the test failure somewhat correctly (not perfectly).
>>> With a multi threaded approach I would expect an LLDB crash to take down
>>> the full test run what isn't something we want.
>>>
>>> On Tue, Sep 22, 2015 at 12:03 AM Zachary Turner via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 After our last discussion, I thought about it some more and there are
 at least some problems with this.  The biggest problem is that with only a
 single process, you are doing all tests from effectively a single instance
 of LLDB.  There's a TestMultipleDebuggers.py for example, and whether or
 not that test passes is equivalent to whether or not the test suite can
 even work without dying horribly.  In other words, you are inherently
 relying on multiple debuggers working to even run the test suite.

 I don't know if that's a problem, but at the very least, it's kind of
 unfortunate.  And of course the problem grows to other areas.  What other
 things fail horribly when a single instance of LLDB is debugging 100
 processes at the same time?

 It's worth adding this as an alternate run mode, but I don't think we
 should make it default until it's more battle-tested.

 On Mon, Sep 21, 2015 at 12:49 PM Todd Fiala via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> Hi all,
>
> I'm considering changing the default lldb test runner from
> multiprocessing-based to threading-based.  Long ago I switched it from
> threading to multiprocessing.  The only reason I did this was because OS X
> was failing to allow more than one exec at a time in the worker threads -
> way down in the Python Global Interpreter Lock (GIL).  And, at the time, I
> didn't have the time to break out the test runner strategies.
>
> We have verified the threading-based issue is no longer manifesting on
> OS X 10.10 and 10.11 beta.  That being the case, I'd like to convert us
> back to being threading-based by default.  Specifically, this will have 
> the
> same effect as doing the following:
> (non-Windows): --test-runner-name threading
> (Windows): --test-runner-name threading-pool
>
> There are a couple benefits here:
> 1. We'll remove a fork for creating the worker queues.  Each of those
> are just threads when using threading, rather than being forked processes.
> Depending on the underlying OS, a thread is typically cheaper.  Also, some
> of the inter-worker communication now becomes cheap intra-process
> communication instead of heavier multiprocessing constructs.
> 2. Debugging is a bit easier.  The worker queues make a lot of noise
> in 'ps aux'-style 

Re: [lldb-dev] r247953 - TypeSystem is now a plugin interface

[Zachary Turner via lldb-dev]

Resending since I sent to wrong list again.

On Tue, Sep 22, 2015 at 10:12 AM Zachary Turner  wrote:

> In regards to this CL:
> http://llvm.org/viewvc/llvm-project?rev=247953&view=rev
>
> It has broken TestCppValueCast on Windows and fixed TestCxxWcharT on
> Windows as well.  Although these appear to be platform specific behavioral
> changes, as I don't see anyone else reporting failures or fixes, the
> description of the CL leads me to infer that this change was supposed to
> have no functional change.  I haven't gotten any response pinging the
> thread so I'll pose it to the wider list for visibility in case someone can
> shed some light on this.  In particular, is this supposed to come with a
> functional change, and if so what?
>
> Unfortunately I don't have buildbots running tests on Windows yet, so I
> can't justify reverting the CL (and it's too old to revert now anyway since
> other things depend on it), but it would greatly appreciate if someone can
> take a look at this and see if they can identify the source of the
> behavioral change
>
> I do plan to have a buildbot running tests within a week or two, so
> hopefully we can catch this kind of thing much sooner next time.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Diffusion] rL248282: test runner: Unix systems now put inferior dotest in its own process group.

[Zachary Turner via lldb-dev]

Thanks for the heads up, I'm familiar with the flag.  I'll look into
whether it's appropriate when I get back from CppCon

On Tue, Sep 22, 2015 at 8:44 AM Todd Fiala  wrote:

> Hey Zachary,
>
> There is a Windows-specific subprocess.CREATE_NEW_PROCESS_GROUP flag that
> you could potentially add to the Windows branch of the suprocess creation
> call in dosep.py.  I'm not sure how useful that is on the Windows end as
> this is mostly about console signal isolation, but I thought I'd call it
> out in case you were interested in adding that to the Windows inferior
> dotest.py creation.
>
> -Todd
>
> On Tue, Sep 22, 2015 at 8:23 AM, Todd Fiala  wrote:
>
>> tfiala committed rL248282: test runner: Unix systems now put inferior
>> dotest in its own process group..
>>
>> test runner: Unix systems now put inferior dotest in its own process
>> group.
>>
>> This increases isolation as it relates to signal handling between parent
>> and
>> children.
>>
>>
>> Files:
>>   /lldb/trunk/test/dosep.py
>>
>> Users:
>>   tfiala (Author)
>>
>> http://reviews.llvm.org/rL248282
>>
>>
>>
>>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Diffusion] rL248282: test runner: Unix systems now put inferior dotest in its own process group.

[Todd Fiala via lldb-dev]

Okay!

On Tue, Sep 22, 2015 at 10:14 AM, Zachary Turner  wrote:

> Thanks for the heads up, I'm familiar with the flag.  I'll look into
> whether it's appropriate when I get back from CppCon
>
> On Tue, Sep 22, 2015 at 8:44 AM Todd Fiala  wrote:
>
>> Hey Zachary,
>>
>> There is a Windows-specific subprocess.CREATE_NEW_PROCESS_GROUP flag that
>> you could potentially add to the Windows branch of the suprocess creation
>> call in dosep.py.  I'm not sure how useful that is on the Windows end as
>> this is mostly about console signal isolation, but I thought I'd call it
>> out in case you were interested in adding that to the Windows inferior
>> dotest.py creation.
>>
>> -Todd
>>
>> On Tue, Sep 22, 2015 at 8:23 AM, Todd Fiala  wrote:
>>
>>> tfiala committed rL248282: test runner: Unix systems now put inferior
>>> dotest in its own process group..
>>>
>>> test runner: Unix systems now put inferior dotest in its own process
>>> group.
>>>
>>> This increases isolation as it relates to signal handling between parent
>>> and
>>> children.
>>>
>>>
>>> Files:
>>>   /lldb/trunk/test/dosep.py
>>>
>>> Users:
>>>   tfiala (Author)
>>>
>>> http://reviews.llvm.org/rL248282
>>>
>>>
>>>
>>>
>>
>>
>> --
>> -Todd
>>
>


-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Ubuntu 15.10 B1 test results

[Todd Fiala via lldb-dev]

Hi all,
FYI -

I just gave a build of lldb @248306 on a Ubuntu 15.10 Beta 1 VM running
under a VMWare hypervisor.

Here's what I saw:

LLDB build with clang-3.7 / tests run with inferiors built with gcc 5.2.1
(defaults gcc):

Ran 398 test suites (10 failed) (2.512563%)

Ran 411 test cases (10 failed) (2.433090%)

Failing Tests (10)
FAIL: LLDB (suite) :: TestConvenienceVariables.py (Linux ub1510
4.2.0-10-generic #12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64 x86_64)

FAIL: LLDB (suite) :: TestDataFormatterSkipSummary.py (Linux ub1510
4.2.0-10-generic #12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64 x86_64)

FAIL: LLDB (suite) :: TestDataFormatterStdIterator.py (Linux ub1510
4.2.0-10-generic #12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64 x86_64)

FAIL: LLDB (suite) :: TestDataFormatterStdList.py (Linux ub1510
4.2.0-10-generic #12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64 x86_64)

FAIL: LLDB (suite) :: TestDataFormatterStdMap.py (Linux ub1510
4.2.0-10-generic #12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64 x86_64)

FAIL: LLDB (suite) :: TestDataFormatterStdString.py (Linux ub1510
4.2.0-10-generic #12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64 x86_64)

FAIL: LLDB (suite) :: TestSBValuePersist.py (Linux ub1510 4.2.0-10-generic
#12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64 x86_64)

FAIL: LLDB (suite) :: TestStepOverWatchpoint.py (Linux ub1510
4.2.0-10-generic #12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64 x86_64)

FAIL: LLDB (suite) :: TestStringPrinter.py (Linux ub1510 4.2.0-10-generic
#12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64 x86_64)

FAIL: LLDB (suite) :: TestTypeCompletion.py (Linux ub1510 4.2.0-10-generic
#12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64 x86_64)

Unexpected Successes (1)

UNEXPECTED SUCCESS: LLDB (suite) :: TestWatchedVarHitWhenInScope.py (Linux
ub1510 4.2.0-10-generic #12-Ubuntu SMP Tue Sep 15 19:43:01 UTC 2015 x86_64
x86_64)

LLDB built with clang-3.7 / test inferiors built with clang-3.7:
Same exact list as above.

Configuration:
Ubuntu 15.10 Beta 1, Gnome edition, desktop, here
.

Package installation:
sudo apt-get update
sudo apt-get dist-upgrade build-essential ninja-build subversion git cmake
python-dev swig libedit-dev ncurses-dev libc++-dev clang-3.4 clang-3.5
clang-3.6 clang-3.7

-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

[Todd Fiala via lldb-dev]

I went ahead and changed this here:

Sendingtest/dosep.py
Transmitting file data .
Committed revision 248323.

I'll be watching the Linux test runner.  I've been using it on Linux and OS
X for a while now.

Zachary, if you have trouble on Windows, we can have the Windows one go
back to defaulting to multiprocessing-pool.  But unless it's a problem, it
would be great to keep it on the simpler threading-pool.  It should be
easier for you to watch it in a debugger, too.

-Todd

On Tue, Sep 22, 2015 at 10:04 AM, Zachary Turner  wrote:

> Ahh right, of course.  Disregard my comment then, I forgot about that
> extra layer
>
> On Tue, Sep 22, 2015 at 8:53 AM Todd Fiala  wrote:
>
>> On Tue, Sep 22, 2015 at 8:49 AM, Todd Fiala  wrote:
>>
>>> Hey guys,
>>>
>>> I think you're misunderstanding the process structure here.
>>>
>>> The threading-based parallel test runner still execs out to a child
>>> *process* for the inferio dotest.py run.  So suggesting we move to
>>> threading is not going to put all tests in a single LLDB process.  We will
>>> always want to be testing lldb with process isolation per dotest.py
>>> inferior call.
>>>
>>> The multiprocessing-based parallel test runner really has an extra layer
>>> of process involved.  Each worker is a separate process (per the
>>> multiprocessing model), which then execs a child process which is
>>> dotest.py.
>>>
>>
>> I'm being fast and loose with "execs" in the sentence above.  It creates
>> a child process (not execs into it) from the multiprocessing worker
>> process.  The same worker multiprocessing process hangs around and services
>> all items for that worker queue.  That process is the extra bloat we get
>> rid of and convert to a thread in the threading model.  That also allows us
>> to use lighter primitives for main-test-runner / worker communication,
>> which no longer need one or more processes just to manage communication
>> between them (implementation details of multiprocessing.Queue and
>> multiprocessing.Manager, for example).
>>
>>
>>> So every inferior dotest.py has a process (the inferior dotest.py
>>> process) and the multiprocess-based worker process.  With the
>>> threading-based test runner, every dotest.py inferior test process is its
>>> own isolated process, and it's driven by a test runner thread in the main
>>> dotest.py process.
>>>
>>> We are not changing anything about the semantics of the test execution
>>> itself when we do this, nor do we impact the reporting in any way.  It's
>>> purely a test running infrastructural change that happens to be more
>>> efficient on most OSes due to the lighter weight of the a thread in most
>>> places vs. a full-blown process.
>>>
>>> On Tue, Sep 22, 2015 at 2:32 AM, Tamas Berghammer <
>>> tbergham...@google.com> wrote:
>>>
 One more point to Zachary's comment is that currently if LLDB crashes
 for a test we report the test failure somewhat correctly (not perfectly).
 With a multi threaded approach I would expect an LLDB crash to take down
 the full test run what isn't something we want.

 On Tue, Sep 22, 2015 at 12:03 AM Zachary Turner via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> After our last discussion, I thought about it some more and there are
> at least some problems with this.  The biggest problem is that with only a
> single process, you are doing all tests from effectively a single instance
> of LLDB.  There's a TestMultipleDebuggers.py for example, and whether or
> not that test passes is equivalent to whether or not the test suite can
> even work without dying horribly.  In other words, you are inherently
> relying on multiple debuggers working to even run the test suite.
>
> I don't know if that's a problem, but at the very least, it's kind of
> unfortunate.  And of course the problem grows to other areas.  What other
> things fail horribly when a single instance of LLDB is debugging 100
> processes at the same time?
>
> It's worth adding this as an alternate run mode, but I don't think we
> should make it default until it's more battle-tested.
>
> On Mon, Sep 21, 2015 at 12:49 PM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I'm considering changing the default lldb test runner from
>> multiprocessing-based to threading-based.  Long ago I switched it from
>> threading to multiprocessing.  The only reason I did this was because OS 
>> X
>> was failing to allow more than one exec at a time in the worker threads -
>> way down in the Python Global Interpreter Lock (GIL).  And, at the time, 
>> I
>> didn't have the time to break out the test runner strategies.
>>
>> We have verified the threading-based issue is no longer manifesting
>> on OS X 10.10 and 10.11 beta.  That being the case, I'd like to convert 
>> us
>> back to being threading-based by default.  Specifically, this

[lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses

[via lldb-dev]

We have a case where a source breakpoint isn't hit because the source line maps
to 2 addresses in the debug info and lldb only sets 1 BP on the first address
which is in a basic block that is rarely executed.  The codegen looks something
like this (in pseudo code):

some_code
br lbl2
lbl1:
some_more_code
code_for_line_50_pt1  ; lldb sets BP here but code not executed
lbl2:
code_for_line_48
code_for_line_50_pt2  ; this code is executed
if (cond) br lbl1

BreakpointResolverFileLine::SearchCallback correctly finds both symbol contexts
for the line.  The symbol contexts have different addresses but the same
lldb_private::Block.  As a result, BreakpointResolver::SetSCMatchesByLine
thinks they are in the same "contiguous range" and removes the 2nd symbol
context.  lldb sets the breakpoint at the 1st address and the user never hits
their breakpoint.

The check for a "contiguous range" in BreakpointResolver::SetSCMatchesByLine
seems wrong.  Is it assuming a Block is actually a basic block (i.e. with no
branches)?  What's supposed to happen here?

Thanks,
-Dawn
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev