Re: [lldb-dev] lldb/test/API/commands/help/TestHelp.py not running just-built lldb

2021-01-20 Thread Greg Clayton via lldb-dev
Might be an easy fix to have our test suite unset the "LD_LIBRARY_PATH" env var 
if it is set?

> On Jan 19, 2021, at 5:38 PM, David Blaikie via lldb-dev 
>  wrote:
> 
> Jonas helped me out here (Thanks!)
> 
> Seems I was setting LD_LIBRARY_PATH for, so far as I recall, good reasons (I 
> have some things installed locally in $HOME/install and I thought somewhere 
> in the mists of time the executables ($HOME/install/bin) didn't naturally 
> find some shared libraries in $HOME/install/lib{,64}) but it was definitely 
> messing up the lldb test execution - so for now I've unset LD_LIBRARY_PATH 
> and I'll leave it that way/see if I rediscover what motivated me to set it in 
> the first place - if that comes up I'll have something more concrete to 
> discuss. But for now I'm unblocked/not hitting this issue anymore.
> 
> Thanks again,
> - Dave
> 
> On Tue, Jan 19, 2021 at 3:56 PM David Blaikie  > wrote:
> On Linux (Ubuntu) + cmake + ninja, it seems this test isn't testing the 
> checked-out lldb, but instead running the system (or user-dir, in my case) 
> installed lldb (see examples at the end of this email)
> 
> If I remove the user-dir installed lldb then the test fails differently - 
> complaining that it can't find the lldb python bindings, it seems. So it's 
> not even falling back to the just-built lldb, by the looks of it.
> 
> Any ideas? Anyone else come across this? Should something in the testing be 
> setting PYTHONPATH to include (preferentially/early) the just-built python 
> lldb package?
> 
> - Dave
> 
> 
> $ ./bin/llvm-lit -v tools/lldb/test/API/commands/help/TestHelp.py
> -- Testing: 1 tests, 1 workers --
> FAIL: lldb-api :: commands/help/TestHelp.py (1 of 1)
>  TEST 'lldb-api :: commands/help/TestHelp.py' FAILED 
> 
> Script:
> --
> /usr/bin/python3 
> /usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/dotest.py -u 
> CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy 
> --env 
> LLVM_LIBS_DIR=/usr/local/google/home/blaikie/dev/llvm/build/default/./lib 
> --arch x86_64 --build-dir 
> /usr/local/google/home/blaikie/dev/llvm/build/default/lldb-test-build.noindex 
> --lldb-module-cache-dir 
> /usr/local/google/home/blaikie/dev/llvm/build/default/lldb-test-build.noindex/module-cache-lldb/lldb-api
>  --clang-module-cache-dir 
> /usr/local/google/home/blaikie/dev/llvm/build/default/lldb-test-build.noindex/module-cache-clang/lldb-api
>  --executable 
> /usr/local/google/home/blaikie/dev/llvm/build/default/./bin/lldb --compiler 
> /usr/local/google/home/blaikie/dev/llvm/build/default/./bin/clang --dsymutil 
> /usr/local/google/home/blaikie/dev/llvm/build/default/./bin/dsymutil 
> --filecheck 
> /usr/local/google/home/blaikie/dev/llvm/build/default/./bin/FileCheck 
> --yaml2obj 
> /usr/local/google/home/blaikie/dev/llvm/build/default/./bin/yaml2obj 
> --lldb-libs-dir /usr/local/google/home/blaikie/dev/llvm/build/default/./lib 
> /usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/commands/help -p 
> TestHelp.py
> --
> Exit Code: -11
> 
> Command Output (stdout):
> --
> lldb version 12.0.0 (g...@github.com:llvm/llvm-project.git revision 
> d49974f9c98ebce5a679eced9f27add138b881fa)
>   clang revision d49974f9c98ebce5a679eced9f27add138b881fa
>   llvm revision d49974f9c98ebce5a679eced9f27add138b881fa
> 
> --
> Command Output (stderr):
> --
> Fatal Python error: Segmentation fault
> 
> Current thread 0x7fe870b7d740 (most recent call first):
>   File 
> "/usr/local/google/home/blaikie/install/lib/python3/dist-packages/lldb/__init__.py",
>  line 3098 in HandleCommand
>   File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>  line 2146 in runCmd
>   File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/commands/help/TestHelp.py",
>  line 62 in test_help_memory_read_should_not_crash_lldb
>   File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/decorators.py",
>  line 345 in wrapper
>   File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/third_party/Python/module/unittest2/unittest2/case.py",
>  line 413 in runMethod
>   File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/third_party/Python/module/unittest2/unittest2/case.py",
>  line 383 in run
>   File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/third_party/Python/module/unittest2/unittest2/case.py",
>  line 458 in __call__
>   File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
>  line 117 in _wrapped_run
>   File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
>  line 115 in _wrapped_run
>   File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/third_party/Python/module/unittest2/unittest2/suite.py",
>  line 85 in run
>   File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/third_party/Python/mod

Re: [lldb-dev] [Release-testers] RFC: Upcoming release schedules and creating a formal schedule for future releases

2021-01-20 Thread Tom Stellard via lldb-dev

On 1/4/21 8:32 PM, Tom Stellard via Release-testers wrote:

Hi,

I want to give an update on the status of the LLVM 11 and LLVM 12 
releases.  11.0.1-final is expected to be tagged this week, along with 
11.1.0-rc1.  Unfortunately, we had an ABI regression in libclang.so 
between LLVM 10 and LLVM 11, so we need to do an 11.1.0 release to 
correct this.  This happened one other time where we had to bump the 
minor version to correct an ABI breakage.  So, LLVM 11.0.1 libclang will 
be ABI compatible with LLVM 11, and LLVM 11.1.0 libclang will be ABI 
compatible  with LLVM != 11.


For LLVM 12 the proposed branch date is Jan 26.  I'm hoping we will have 
the 2 LLVM 11.x releases done before that.


In addition to all this, I would like to propose an official 
week-of-the-year based release schedule that we can use for all future 
releases.  What I'm proposing is not really any different in terms of 
dates from what we've been doing for the last several years.  My main 
goal is just to get this documented so it's clear to the community and 
the release managers what the expectations are.  Here is the proposed 
scheduled:


1.0.0-rc1   4th Tue in January
1.0.0-rc2   + 4 Weeks
1.0.0-final + 2 Weeks  (10th Tuesday ~mar 9)
1.0.1-rc1   + 4 Weeks
1.0.1-rc2   + 4 Weeks
1.0.1-final + 2 Weeks  (20th Tuesday ~may 18)

2.0.0-rc1   + 10 Weeks (+26 Weeks From 1.0.0-rc1)
2.0.0-rc2   +  4 Weeks
2.0.0-final +  2 weeks (36th Tuesday ~sep 7)
2.0.1-rc1   +  4 weeks
2.0.1-rc2   +  4 weeks
2.0.1-final +  2 weeks (46th Tuesday ~nov 16

The release branches will be created on the same day as -rc1.

If there are no objections to this, I will add it to the documentation 
next week.




Thanks for the feedback, I have incorporated all the suggestions and 
submitted a patch to update the documentation:

https://reviews.llvm.org/D95114

-Tom


-Tom

___
Release-testers mailing list
release-test...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers


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


[lldb-dev] Reminder: release/12.x branch will be created in 6 days

2021-01-20 Thread Tom Stellard via lldb-dev

Hi,

I will be creating the release/12.x branch next Tuesday and tagging 
12.0.0-rc1 shortly after.


-Tom

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