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
https://llvm.org/bugs/show_bug.cgi?id=21620
ema...@freebsd.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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 p
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 dat
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 ne
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
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 a
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 par
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
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
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 s
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 faile
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 defa
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 lbl
16 matches
Mail list logo
