[lldb-dev] [Bug 25653] Cannot inspect const static variable

[via lldb-dev]

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

Ewan Crawford  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Ewan Crawford  ---
Fixed in revision r255887

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

[lldb-dev] [Bug 25866] New: Gentoo Linux build breaks in some scenarios when both Python 2 and Python 3 are present

[via lldb-dev]

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

Bug ID: 25866
   Summary: Gentoo Linux build breaks in some scenarios when both
Python 2 and Python 3 are present
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

This may be the same thing as the issue on Arch Linux; however, one of the
threads on this indicated some tweaking of build environment variables allowed
this to work.

I suspect the fix for handling python 2 and python 3 simultaneously with
preferential treatment for python 2 would handle this.  Filing in case this is
a different issue.

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

[lldb-dev] [Bug 25869] New: OS X lldb crashed during test: ProcessGDBRemote/Broadcaster cleanup segfault

[via lldb-dev]

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

Bug ID: 25869
   Summary: OS X lldb crashed during test:
ProcessGDBRemote/Broadcaster cleanup segfault
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15480
  --> https://llvm.org/bugs/attachment.cgi?id=15480&action=edit
crashlog

This is on my home iMac, running against lldb r255893.  Crashlog attached.

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

[lldb-dev] mind if I try allowing reruns on arm/aarch64?

[Todd Fiala via lldb-dev]

Hi Ying,

I am speculating that the rerun logic issue where we saw the hang may be
more of a serial test runner issue.  Would you mind if I re-enabled the
arm/aarch64 inclusion in the rerun logic now that I made a change based on
this speculation?  It would be a relatively quick way to check if the
serial test runner is the issue, since now the rerun logic will not use the
serial test runner but rather the normal parallel runner with a single
worker (so, the same intent but expressed another way, using the test
runners we use all the time).  If we still hit the issue, it is unrelated
to the serial test runner strategy.  If we don't see the issue, then: (1)
great, we have a solution, and (2) I know I need to look into the serial
test runner strategy which may need some updates for recent changes.

How does that sound?  If I enable it and it times out, I'll just revert the
change and we'll go back to normal.  (And I'll know more about the issue,
albeit with more investigation necessary).  If it works just fine, we'll
leave it this way (and I'll know I need to look into the serial test
runner).

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

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

[Todd Fiala via lldb-dev]

(And, as an aside, I may just nuke the serial test runner anyway, since we
can do it with a multi-worker runner with a single worker just fine, and
reduce the code size --- I really don't see a good reason to keep the
serial test runner strategy anymore except for a purely theoretical sense).

On Thu, Dec 17, 2015 at 10:37 AM, Todd Fiala  wrote:

> Hi Ying,
>
> I am speculating that the rerun logic issue where we saw the hang may be
> more of a serial test runner issue.  Would you mind if I re-enabled the
> arm/aarch64 inclusion in the rerun logic now that I made a change based on
> this speculation?  It would be a relatively quick way to check if the
> serial test runner is the issue, since now the rerun logic will not use the
> serial test runner but rather the normal parallel runner with a single
> worker (so, the same intent but expressed another way, using the test
> runners we use all the time).  If we still hit the issue, it is unrelated
> to the serial test runner strategy.  If we don't see the issue, then: (1)
> great, we have a solution, and (2) I know I need to look into the serial
> test runner strategy which may need some updates for recent changes.
>
> How does that sound?  If I enable it and it times out, I'll just revert
> the change and we'll go back to normal.  (And I'll know more about the
> issue, albeit with more investigation necessary).  If it works just fine,
> we'll leave it this way (and I'll know I need to look into the serial test
> runner).
>
> --
> -Todd
>



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

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

[Ying Chen via lldb-dev]

Yes, you could use android builder to run that experiment.
Please watch test 7 of this builder
 after
your change goes in(Another test for aarch64 which was previously timed out
has been disabled for offline debugging of other unrelated problems).

Thanks,
Ying

On Thu, Dec 17, 2015 at 10:39 AM, Todd Fiala  wrote:

> (And, as an aside, I may just nuke the serial test runner anyway, since we
> can do it with a multi-worker runner with a single worker just fine, and
> reduce the code size --- I really don't see a good reason to keep the
> serial test runner strategy anymore except for a purely theoretical sense).
>
> On Thu, Dec 17, 2015 at 10:37 AM, Todd Fiala  wrote:
>
>> Hi Ying,
>>
>> I am speculating that the rerun logic issue where we saw the hang may be
>> more of a serial test runner issue.  Would you mind if I re-enabled the
>> arm/aarch64 inclusion in the rerun logic now that I made a change based on
>> this speculation?  It would be a relatively quick way to check if the
>> serial test runner is the issue, since now the rerun logic will not use the
>> serial test runner but rather the normal parallel runner with a single
>> worker (so, the same intent but expressed another way, using the test
>> runners we use all the time).  If we still hit the issue, it is unrelated
>> to the serial test runner strategy.  If we don't see the issue, then: (1)
>> great, we have a solution, and (2) I know I need to look into the serial
>> test runner strategy which may need some updates for recent changes.
>>
>> How does that sound?  If I enable it and it times out, I'll just revert
>> the change and we'll go back to normal.  (And I'll know more about the
>> issue, albeit with more investigation necessary).  If it works just fine,
>> we'll leave it this way (and I'll know I need to look into the serial test
>> runner).
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 25872] New: OS X: TestGlobalVariables dwarf is not finding the static const int g_file_static_int

[via lldb-dev]

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

Bug ID: 25872
   Summary: OS X: TestGlobalVariables dwarf is not finding the
static const int g_file_static_int
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

This looks like it started happening very recently:

runCmd: frame variable --show-types --scope --show-globals --no-args
output: STATIC: (const char *) g_func_static_cstr = 0x000103c65f69
"g_func_static_cstr"
STATIC: (const char *) g_file_static_cstr = 0x000103c65f83
"g_file_static_cstr"
STATIC: (const char *) g_func_static_cstr = 0x000103c65f69
"g_func_static_cstr"
GLOBAL: (const char *) g_file_global_cstr = 0x000103c65f56
"g_file_global_cstr"
GLOBAL: (int) g_common_1 = 21
GLOBAL: (int) g_file_global_int = 42


Expecting sub string: GLOBAL: (int) g_file_global_int = 42
Matched

Expecting sub string: STATIC: (const int) g_file_static_int = 2
Not matched

FAIL

 >>: success

Traceback (most recent call last):
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2263, in dwarf_test_method
return attrvalue(self)
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 608, in wrapper
func(*args, **kwargs)
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lang/c/global_variables/TestGlobalVariables.py",
line 60, in test
'GLOBAL: (int) g_common_1 = 21'])
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2715, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Variable(s) displayed correctly
Config=x86_64-clang
Session info generated @ Thu Dec 17 10:46:37 2015
To rerun this test, issue the following command from the 'test' directory:

./dotest.py -A x86_64 -C clang -v -t  -f GlobalVariablesTestCase.test_dwarf


OS X 10.11.2 (15C50)
Xcode 7.2 (7C68)

-- 
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] mind if I try allowing reruns on arm/aarch64?

[Todd Fiala via lldb-dev]

Excellent.  I'll try this in the afternoon.  I need to run out now but I'll
check in what we discussed later on when I get back.

Thanks!

On Thu, Dec 17, 2015 at 10:51 AM, Ying Chen  wrote:

> Yes, you could use android builder to run that experiment.
> Please watch test 7 of this builder
>  after
> your change goes in(Another test for aarch64 which was previously timed out
> has been disabled for offline debugging of other unrelated problems).
>
> Thanks,
> Ying
>
> On Thu, Dec 17, 2015 at 10:39 AM, Todd Fiala  wrote:
>
>> (And, as an aside, I may just nuke the serial test runner anyway, since
>> we can do it with a multi-worker runner with a single worker just fine, and
>> reduce the code size --- I really don't see a good reason to keep the
>> serial test runner strategy anymore except for a purely theoretical sense).
>>
>> On Thu, Dec 17, 2015 at 10:37 AM, Todd Fiala 
>> wrote:
>>
>>> Hi Ying,
>>>
>>> I am speculating that the rerun logic issue where we saw the hang may be
>>> more of a serial test runner issue.  Would you mind if I re-enabled the
>>> arm/aarch64 inclusion in the rerun logic now that I made a change based on
>>> this speculation?  It would be a relatively quick way to check if the
>>> serial test runner is the issue, since now the rerun logic will not use the
>>> serial test runner but rather the normal parallel runner with a single
>>> worker (so, the same intent but expressed another way, using the test
>>> runners we use all the time).  If we still hit the issue, it is unrelated
>>> to the serial test runner strategy.  If we don't see the issue, then: (1)
>>> great, we have a solution, and (2) I know I need to look into the serial
>>> test runner strategy which may need some updates for recent changes.
>>>
>>> How does that sound?  If I enable it and it times out, I'll just revert
>>> the change and we'll go back to normal.  (And I'll know more about the
>>> issue, albeit with more investigation necessary).  If it works just fine,
>>> we'll leave it this way (and I'll know I need to look into the serial test
>>> runner).
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>


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

[lldb-dev] lists.llvm.org server maintenance, Friday Dec 18 @10:30 PST

[Tanya Lattner via lldb-dev]

All,

The server that runs the mailing lists will be down for maintenance starting 
Friday Dec 18th at 10:30PM PST. I do not expect a long downtime, but please 
keep this in mind if you see any issues with the lists during this period. I 
will send an email once I am finished.

No other services should be affected.

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

[lldb-dev] building on mac

[Ryan Brown via lldb-dev]

Are there new prereqs for building on a mac?
I just updated, and I'm getting this error:

checking for __dso_handle... yes

configure: WARNING: --enable-bindings=ocaml specified, but ctypes is not
installed

configure: WARNING: --enable-bindings=ocaml specified, but OUnit 2 is not
installed. Tests will not run

configure: error: Prequisites for bindings not satisfied. Fix them or use
configure --disable-bindings.

error: making llvm and clang child exited with value 2


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

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

[Todd Fiala via lldb-dev]

Hi Ying,

I just put this change in that reverted the aarch64 and arm removal from
test-rerun eligibility:

r255935.

I'll watch this builder
 now
and see what happens.  If it hangs on reruns, I'll revert r255935.

Thanks!

-Todd

On Thu, Dec 17, 2015 at 11:18 AM, Todd Fiala  wrote:

> Excellent.  I'll try this in the afternoon.  I need to run out now but
> I'll check in what we discussed later on when I get back.
>
> Thanks!
>
> On Thu, Dec 17, 2015 at 10:51 AM, Ying Chen  wrote:
>
>> Yes, you could use android builder to run that experiment.
>> Please watch test 7 of this builder
>>  after
>> your change goes in(Another test for aarch64 which was previously timed out
>> has been disabled for offline debugging of other unrelated problems).
>>
>> Thanks,
>> Ying
>>
>> On Thu, Dec 17, 2015 at 10:39 AM, Todd Fiala 
>> wrote:
>>
>>> (And, as an aside, I may just nuke the serial test runner anyway, since
>>> we can do it with a multi-worker runner with a single worker just fine, and
>>> reduce the code size --- I really don't see a good reason to keep the
>>> serial test runner strategy anymore except for a purely theoretical sense).
>>>
>>> On Thu, Dec 17, 2015 at 10:37 AM, Todd Fiala 
>>> wrote:
>>>
 Hi Ying,

 I am speculating that the rerun logic issue where we saw the hang may
 be more of a serial test runner issue.  Would you mind if I re-enabled the
 arm/aarch64 inclusion in the rerun logic now that I made a change based on
 this speculation?  It would be a relatively quick way to check if the
 serial test runner is the issue, since now the rerun logic will not use the
 serial test runner but rather the normal parallel runner with a single
 worker (so, the same intent but expressed another way, using the test
 runners we use all the time).  If we still hit the issue, it is unrelated
 to the serial test runner strategy.  If we don't see the issue, then: (1)
 great, we have a solution, and (2) I know I need to look into the serial
 test runner strategy which may need some updates for recent changes.

 How does that sound?  If I enable it and it times out, I'll just revert
 the change and we'll go back to normal.  (And I'll know more about the
 issue, albeit with more investigation necessary).  If it works just fine,
 we'll leave it this way (and I'll know I need to look into the serial test
 runner).

 --
 -Todd

>>>
>>>
>>>
>>> --
>>> -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] building on mac

[Todd Fiala via lldb-dev]

We definitely should not be requiring ocaml :-)

Are you using a configure-based build?  If so, can you switch over to using
cmake and see if you see that same issue?  We pretty much don't maintain
the configure build, and it is getting stripped from llvm and clang in the
next version of them after 3.8, so we will not be able to support
configure-based builds in the near future.

In the event that you still see it, let us know if you have ocaml or opam
somewhere on your system.  The warnings do seem to indicate that ocaml was
specified for one reason or another?  Maybe parts of it were sniffed out
when trying to configure the build.

-Todd

On Thu, Dec 17, 2015 at 1:36 PM, Ryan Brown via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Are there new prereqs for building on a mac?
> I just updated, and I'm getting this error:
>
> checking for __dso_handle... yes
>
> configure: WARNING: --enable-bindings=ocaml specified, but ctypes is not
> installed
>
> configure: WARNING: --enable-bindings=ocaml specified, but OUnit 2 is not
> installed. Tests will not run
>
> configure: error: Prequisites for bindings not satisfied. Fix them or use
> configure --disable-bindings.
>
> error: making llvm and clang child exited with value 2
>
>
> -- Ryan Brown
>
> ___
> 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] building on mac

[Ryan Brown via lldb-dev]

Does xcode use configure? I just push command-B.
It does look like I have ocaml installed on my system, but I'm not sure how
it go installed or why xcode is trying to use it.

-- Ryan Brown

On Thu, Dec 17, 2015 at 2:54 PM, Todd Fiala  wrote:

> We definitely should not be requiring ocaml :-)
>
> Are you using a configure-based build?  If so, can you switch over to
> using cmake and see if you see that same issue?  We pretty much don't
> maintain the configure build, and it is getting stripped from llvm and
> clang in the next version of them after 3.8, so we will not be able to
> support configure-based builds in the near future.
>
> In the event that you still see it, let us know if you have ocaml or opam
> somewhere on your system.  The warnings do seem to indicate that ocaml was
> specified for one reason or another?  Maybe parts of it were sniffed out
> when trying to configure the build.
>
> -Todd
>
> On Thu, Dec 17, 2015 at 1:36 PM, Ryan Brown via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Are there new prereqs for building on a mac?
>> I just updated, and I'm getting this error:
>>
>> checking for __dso_handle... yes
>>
>> configure: WARNING: --enable-bindings=ocaml specified, but ctypes is not
>> installed
>>
>> configure: WARNING: --enable-bindings=ocaml specified, but OUnit 2 is not
>> installed. Tests will not run
>>
>> configure: error: Prequisites for bindings not satisfied. Fix them or use
>> configure --disable-bindings.
>>
>> error: making llvm and clang child exited with value 2
>>
>>
>> -- Ryan Brown
>>
>> ___
>> 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] building on mac

[Todd Fiala via lldb-dev]

Ah.

Okay, this might be the llvm/clang build script that Xcode uses as an
llvm/clang build step.  That's going to need to be updated if it is using
configure (for the reasons I mentioned above).

So it sounds like some part of llvm or clang may be sniffing and finding
some part of ocaml, and deciding it should make some bindings for it.  I'll
have a look at the script and see if there's an obvious way to explicitly
deny it (the warning seemed like it had a way to disable that binding, so
we might just need to work it in).

Of course, if you are not using ocaml, you might want to consider
removing/hiding it if you don't need it.

Interestingly, I did have ocaml on my home system a while back and didn't
have any trouble building, but I probably had ounit2 as well, and likely
wouldn't have noticed if the Xcode-based build-llvm script ended up doing
more work when building the embedded llvm/clang during the Xcode build.

 I can probably replicate this pretty easily.

On Thu, Dec 17, 2015 at 3:10 PM, Ryan Brown  wrote:

> Does xcode use configure? I just push command-B.
> It does look like I have ocaml installed on my system, but I'm not sure
> how it go installed or why xcode is trying to use it.
>
> -- Ryan Brown
>
> On Thu, Dec 17, 2015 at 2:54 PM, Todd Fiala  wrote:
>
>> We definitely should not be requiring ocaml :-)
>>
>> Are you using a configure-based build?  If so, can you switch over to
>> using cmake and see if you see that same issue?  We pretty much don't
>> maintain the configure build, and it is getting stripped from llvm and
>> clang in the next version of them after 3.8, so we will not be able to
>> support configure-based builds in the near future.
>>
>> In the event that you still see it, let us know if you have ocaml or opam
>> somewhere on your system.  The warnings do seem to indicate that ocaml was
>> specified for one reason or another?  Maybe parts of it were sniffed out
>> when trying to configure the build.
>>
>> -Todd
>>
>> On Thu, Dec 17, 2015 at 1:36 PM, Ryan Brown via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Are there new prereqs for building on a mac?
>>> I just updated, and I'm getting this error:
>>>
>>> checking for __dso_handle... yes
>>>
>>> configure: WARNING: --enable-bindings=ocaml specified, but ctypes is not
>>> installed
>>>
>>> configure: WARNING: --enable-bindings=ocaml specified, but OUnit 2 is
>>> not installed. Tests will not run
>>>
>>> configure: error: Prequisites for bindings not satisfied. Fix them or
>>> use configure --disable-bindings.
>>>
>>> error: making llvm and clang child exited with value 2
>>>
>>>
>>> -- Ryan Brown
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>> --
>> -Todd
>>
>
>


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

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

[Ying Chen via lldb-dev]

Hi Todd,

Seems the problem is fixed by using parallel runner.
This test exits normally after rerun.
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-android/builds/4357/steps/test7/logs/stdio

On Thu, Dec 17, 2015 at 2:47 PM, Todd Fiala  wrote:

> Hi Ying,
>
> I just put this change in that reverted the aarch64 and arm removal from
> test-rerun eligibility:
>
> r255935.
>
> I'll watch this builder
>  now
> and see what happens.  If it hangs on reruns, I'll revert r255935.
>
> Thanks!
>
> -Todd
>
> On Thu, Dec 17, 2015 at 11:18 AM, Todd Fiala  wrote:
>
>> Excellent.  I'll try this in the afternoon.  I need to run out now but
>> I'll check in what we discussed later on when I get back.
>>
>> Thanks!
>>
>> On Thu, Dec 17, 2015 at 10:51 AM, Ying Chen  wrote:
>>
>>> Yes, you could use android builder to run that experiment.
>>> Please watch test 7 of this builder
>>>  after
>>> your change goes in(Another test for aarch64 which was previously timed out
>>> has been disabled for offline debugging of other unrelated problems).
>>>
>>> Thanks,
>>> Ying
>>>
>>> On Thu, Dec 17, 2015 at 10:39 AM, Todd Fiala 
>>> wrote:
>>>
 (And, as an aside, I may just nuke the serial test runner anyway, since
 we can do it with a multi-worker runner with a single worker just fine, and
 reduce the code size --- I really don't see a good reason to keep the
 serial test runner strategy anymore except for a purely theoretical sense).

 On Thu, Dec 17, 2015 at 10:37 AM, Todd Fiala 
 wrote:

> Hi Ying,
>
> I am speculating that the rerun logic issue where we saw the hang may
> be more of a serial test runner issue.  Would you mind if I re-enabled the
> arm/aarch64 inclusion in the rerun logic now that I made a change based on
> this speculation?  It would be a relatively quick way to check if the
> serial test runner is the issue, since now the rerun logic will not use 
> the
> serial test runner but rather the normal parallel runner with a single
> worker (so, the same intent but expressed another way, using the test
> runners we use all the time).  If we still hit the issue, it is unrelated
> to the serial test runner strategy.  If we don't see the issue, then: (1)
> great, we have a solution, and (2) I know I need to look into the serial
> test runner strategy which may need some updates for recent changes.
>
> How does that sound?  If I enable it and it times out, I'll just
> revert the change and we'll go back to normal.  (And I'll know more about
> the issue, albeit with more investigation necessary).  If it works just
> fine, we'll leave it this way (and I'll know I need to look into the 
> serial
> test runner).
>
> --
> -Todd
>



 --
 -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] mind if I try allowing reruns on arm/aarch64?

[Todd Fiala via lldb-dev]

Great, thanks!  Yes I was just checking after dinner and saw that it looks
to be rerunning just fine.

Okay I am likely to just strip out the serial test runner strategy at this
point.  One less thing to keep running.

Thanks!

-Todd

On Thu, Dec 17, 2015 at 5:41 PM, Ying Chen  wrote:

> Hi Todd,
>
> Seems the problem is fixed by using parallel runner.
> This test exits normally after rerun.
>
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-android/builds/4357/steps/test7/logs/stdio
>
> On Thu, Dec 17, 2015 at 2:47 PM, Todd Fiala  wrote:
>
>> Hi Ying,
>>
>> I just put this change in that reverted the aarch64 and arm removal from
>> test-rerun eligibility:
>>
>> r255935.
>>
>> I'll watch this builder
>>  now
>> and see what happens.  If it hangs on reruns, I'll revert r255935.
>>
>> Thanks!
>>
>> -Todd
>>
>> On Thu, Dec 17, 2015 at 11:18 AM, Todd Fiala 
>> wrote:
>>
>>> Excellent.  I'll try this in the afternoon.  I need to run out now but
>>> I'll check in what we discussed later on when I get back.
>>>
>>> Thanks!
>>>
>>> On Thu, Dec 17, 2015 at 10:51 AM, Ying Chen  wrote:
>>>
 Yes, you could use android builder to run that experiment.
 Please watch test 7 of this builder
  after
 your change goes in(Another test for aarch64 which was previously timed out
 has been disabled for offline debugging of other unrelated problems).

 Thanks,
 Ying

 On Thu, Dec 17, 2015 at 10:39 AM, Todd Fiala 
 wrote:

> (And, as an aside, I may just nuke the serial test runner anyway,
> since we can do it with a multi-worker runner with a single worker just
> fine, and reduce the code size --- I really don't see a good reason to 
> keep
> the serial test runner strategy anymore except for a purely theoretical
> sense).
>
> On Thu, Dec 17, 2015 at 10:37 AM, Todd Fiala 
> wrote:
>
>> Hi Ying,
>>
>> I am speculating that the rerun logic issue where we saw the hang may
>> be more of a serial test runner issue.  Would you mind if I re-enabled 
>> the
>> arm/aarch64 inclusion in the rerun logic now that I made a change based 
>> on
>> this speculation?  It would be a relatively quick way to check if the
>> serial test runner is the issue, since now the rerun logic will not use 
>> the
>> serial test runner but rather the normal parallel runner with a single
>> worker (so, the same intent but expressed another way, using the test
>> runners we use all the time).  If we still hit the issue, it is unrelated
>> to the serial test runner strategy.  If we don't see the issue, then: (1)
>> great, we have a solution, and (2) I know I need to look into the serial
>> test runner strategy which may need some updates for recent changes.
>>
>> How does that sound?  If I enable it and it times out, I'll just
>> revert the change and we'll go back to normal.  (And I'll know more about
>> the issue, albeit with more investigation necessary).  If it works just
>> fine, we'll leave it this way (and I'll know I need to look into the 
>> serial
>> test runner).
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>


>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>


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