Suppress TLS variable leaks caused by outstanding background threads by
suppressing the ASAN interposer functions. This is possible because because
we're now using use_tls=1.
-----------------------
Direct leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x5627a1f0cc86 in __interceptor_realloc (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xb9fc86) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#1 0x7f04d8800f79 in pthread_getattr_np (/lib/x86_64-linux-gnu/libc.so.6+0x95f79) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
#2 0x5627a1f2f664 in __sanitizer::GetThreadStackTopAndBottom(bool, unsigned long*, unsigned long*) (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xbc2664) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#3 0x5627a1f2fb83 in __sanitizer::GetThreadStackAndTls(bool, unsigned long*, unsigned long*, unsigned long*, unsigned long*) (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xbc2b83) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#4 0x5627a1f19a0d in __asan::AsanThread::SetThreadStackAndTls(__asan::AsanThread::InitOptions const*) (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xbaca0d) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#5 0x5627a1f19615 in __asan::AsanThread::Init(__asan::AsanThread::InitOptions const*) (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xbac615) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#6 0x5627a1f19b01 in __asan::AsanThread::ThreadStart(unsigned long long) (/home/runner/work/fish-shell/fish-shell/build/fish_tests+0xbacb01) (BuildId: da87d16730727369ad5fa46052d10337d6941fa9)
#7 0x7f04d87ffb42 (/lib/x86_64-linux-gnu/libc.so.6+0x94b42) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
#8 0x7f04d88919ff (/lib/x86_64-linux-gnu/libc.so.6+0x1269ff) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
Set use_tls back to its default of 1.
This is required to work around an ASAN/LSAN virtualization bug but seems to be
behind the random __cxa_thread_atexit_impl() leaks?
Rust has multiple sanitizers available (with llvm integration).
-Zsanitizer=address catches the most likely culprits but we may want to set up a
separate job w/ -Zsanitizer=memory to catch uninitialized reads.
It might be necessary to execute `cargo build` as `cargo build -Zbuild-std` to
get full coverage.
When we're linking against the hybrid C++ codebase, the sanitizer library is
injected into the binary by also include `-fsanitize=address` in CXXFLAGS - we
do *not* want to manually opt-into `-lasan`. We also need to manually specify
the desired target triple as a CMake variable and then explicitly pass it to all
`cargo` invocations if building with ASAN.
Corrosion has been patched to make sure it follows these rules.
The `cargo-test` target is failing to link under ASAN. For some reason it has
autocxx/ffi dependencies even though only rust-native, ffi-free code should be
tested (and one would think the situation wouldn't change depending on the
presence of the sanitizer flag). It's been disabled under ASAN for now.
In v3 several input parameters where renamed and since v4 it requires Node.js 16.
This resolves warnings about Node.js 12 and `set-output` being deprecated and
slated for removal in the `Lock threads` workflow.
This addresses the node v12 deprecation warning in the GitHub CI, caused by the
dependency on actions/checkout@v2.
While actions/checkout@v3 introduces some new features and changes some
defaults, the subset of features that we use should not be affected by this
migration.
The "breaking change" from v2 to v3 can be seen at [0]. Since we are tracking
only v2 without a dot release specified, we are already opting into any breakage
across minor versions, so really the only change of note is the node version
upgrade.
[0]: https://github.com/actions/checkout/compare/v2.4.2...v3.0.0
It is 1 whole year, for an already closed issue.
Any "engagement" that happens at that point is irrelevant to the
original issue at hand, and a new issue should be opened instead.
Increasing the grace period even further is even less likely to be helpful.
This is a false positive as a result of disabling TLS support in LSAN due to an
incompatibility with newer versions of glibc.
Also remove the older workaround (because it didn't work).
These are NOT build-time defines but rather run-time environment variables! They
have never had any effect and we have effectively never used them to affect
sanitizer behavior under CI with ASAN/UBSAN/LSAN enabled.
(I caught this because the tests don't pass with either of LSAN_OPTIONS
`verbosity=1` or `log_threads=1` because they inject text into the stderr
output, ensuring they never pass littlecheck.)
The current Github Actions ubuntu-latest image crashes in the
autosuggest_suggest_special test with ASAN.
We have not been able to reproduce this locally, and this is getting
in the way.
I have no idea how to disable this test on ASAN specifically, all my
attempts have failed. So the only recourse I know is to disable the
ASAN tests on GA entirely.
This speeds up the CI build, since before it was effectively 1.
Build times on ubuntu-latest are reduced by slightly over 2 minutes.
Note Linux CI runners are defined to have 2 cores and Mac runners 3.
Revert "Move the file - it was trying to triggr stuff."
This reverts commit 108560ff55.
Revert "fixup"
This reverts commit fdc0f2f6a7.
Revert "configure more analyzers, skip vendored stuff."
This reverts commit 023f6683f0.
Revert "Update codeql-analysis.yml"
This reverts commit ea25db544e.
The point here is to let issues be *done*, and have any *new*
discussions happen in *new* issues so you can decouple the context.
This revert pending further discussion.
Set locked thread inactivity count to default 365.
Add 'needs more info' as an obvious on its face exception.
The default seems quite an inconventient, very strict thing t do:
it will lock threads that are closed and quiet because they have
been quiet and closed. This seems to make it hard to talk about
issues after they are closed or contribute. I can as a fish-shell
contributor, but that's not really the point.
Practically, right now to reply to any PR or any issue fixed in
July, well you can't.
