Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable LLVM assertions on Nightly, enable them in "alt" builds. #45810

Merged
merged 3 commits into from
Nov 13, 2017

Conversation

SimonSapin
Copy link
Contributor

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@aturon
Copy link
Member

aturon commented Nov 6, 2017

@bors r+

@bors
Copy link
Contributor

bors commented Nov 6, 2017

📌 Commit eac34c9 has been approved by aturon

@aturon
Copy link
Member

aturon commented Nov 6, 2017

cc @rust-lang/infra, just to keep everyone in the loop on this change.

@kennytm kennytm added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 7, 2017
@kennytm
Copy link
Member

kennytm commented Nov 7, 2017

I think we also need to update .travis.yml to point the try branch to the alt build so crater and perf can still test with assertion enabled.

@SimonSapin
Copy link
Contributor Author

@kennytm I’ve pushed another commit. How does it look?

Though I don’t know if perf should have LLVM assertions, since that produces timings different from what everyone will use.

@kennytm
Copy link
Member

kennytm commented Nov 7, 2017

@SimonSapin Unfortunately, unless we have two try branches we are stuck with either sacrificing perf or crater. At least enabling assertions allows the metrics be comparable before and after this PR.

@bors r=aturon

@bors
Copy link
Contributor

bors commented Nov 7, 2017

📌 Commit dfb08b6 has been approved by aturon

@michaelwoerister
Copy link
Member

@Mark-Simulacrum @alexcrichton Will we back-collect perf.rlo data after this (e.g. by compiling with the former "alt builds" for older nightlies)?

@Mark-Simulacrum
Copy link
Member

Since this will require changes to perf.rlo anyway, I should be able to make it so that we properly collect non-alt before and alt now. Ideally, we'd add something like @bors perf which would output dedicated artifacts for perf (and then we wouldn't have to share between crater, which does want assertions, and perf, which doesn't). It's also worth thinking about tracking how "bad" assertions are.

@michaelwoerister
Copy link
Member

michaelwoerister commented Nov 8, 2017

Ideally, we'd add something like @bors perf which would output dedicated artifacts for perf

It would be nice if perf.rlo tested with debug assertions disabled too since that is closer to how stable releases perform. Also, I'm quite liberal with debug assertions :)

@nikomatsakis
Copy link
Contributor

@Mark-Simulacrum

It's also worth thinking about tracking how "bad" assertions are.

by this do you mean running with assertions both enable and disabled and comparing the results?

@Mark-Simulacrum
Copy link
Member

Yes, exactly.

@shepmaster
Copy link
Member

shepmaster commented Nov 8, 2017

@SimonSapin if you happen to push another commit, can you fix the typo "Nigthly"? It exists existed in the PR title and in your first commit.

@SimonSapin SimonSapin changed the title Disable LLVM assertions on Nigthly, enable them in "alt" builds. Disable LLVM assertions on Nightly, enable them in "alt" builds. Nov 8, 2017
@oyvindln
Copy link
Contributor

Is it a good idea to merge this as long as #45220 isn't solved, given that it may result in that ending up accessing out-of-bounds memory rather than panicking?

@bors
Copy link
Contributor

bors commented Nov 11, 2017

⌛ Testing commit dfb08b6 with merge 9a9ee1b...

bors added a commit that referenced this pull request Nov 11, 2017
@bors
Copy link
Contributor

bors commented Nov 11, 2017

💔 Test failed - status-travis

@SimonSapin
Copy link
Contributor Author

SimonSapin commented Nov 11, 2017

[01:12:34] failures:
[01:12:34] thread 'main' panicked at 'Some tests failed', /checkout/src/tools/compiletest/src/main.rs:331:21
[01:12:34] 
[01:12:34] ---- [run-make] run-make/sanitizer-memory stdout ----
[01:12:34]      
[01:12:34] error: make failed
[01:12:34] status: exit code: 2
[01:12:34] command: "make"
[01:12:34] stdout:
[01:12:34] ------------------------------------------
[01:12:34] LD_LIBRARY_PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/sanitizer-memory.stage2-x86_64-unknown-linux-gnu:/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/deps:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib:" '/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc' --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/sanitizer-memory.stage2-x86_64-unknown-linux-gnu -L /checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/sanitizer-memory.stage2-x86_64-unknown-linux-gnu  -g -Z sanitizer=memory -Z print-link-args uninit.rs | grep -q librustc_msan
[01:12:34] /checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/sanitizer-memory.stage2-x86_64-unknown-linux-gnu/uninit 2>&1 | grep -q use-of-uninitialized-value
[01:12:34] Makefile:6: recipe for target 'all' failed
[01:12:34] 
[01:12:34] ------------------------------------------
[01:12:34] stderr:
[01:12:34] ------------------------------------------
[01:12:34] warning: unused variable: `y`
[01:12:34]   --> uninit.rs:15:9
[01:12:34]    |
[01:12:34] 15 |     let y = xs[0] + xs[1];
[01:12:34]    |         ^
[01:12:34]    |
[01:12:34]    = note: #[warn(unused_variables)] on by default
[01:12:34]    = note: to avoid this warning, consider using `_y` instead
[01:12:34] 
[01:12:34] make: *** [all] Error 1
[01:12:34] 
[01:12:34] ------------------------------------------
[01:12:34] 
[01:12:34] thread '[run-make] run-make/sanitizer-memory' panicked at 'explicit panic', /checkout/src/tools/compiletest/src/runtest.rs:2505:8
[01:12:34] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:12:34] 
[01:12:34] 
[01:12:34] failures:
[01:12:34]     [run-make] run-make/sanitizer-memory
[01:12:34] 
[01:12:34] test result: FAILED. 163 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

I’m trying to reproduce locally.

@kennytm kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 11, 2017
@SimonSapin
Copy link
Contributor Author

SimonSapin commented Nov 11, 2017

:(

$ ./x.py test src/test/run-make --test-args sanitizer-memory
[…]
running 1 test
test [run-make] run-make/sanitizer-memory ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 163 filtered out

@SimonSapin
Copy link
Contributor Author

Ah, this test is entirely inside ifdef SANITIZER_SUPPORT. When building with --enable-sanitizers I get errors below. The relevant part seems to be error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined.

[ 90%] Built target RTAsan_dynamic.x86_64
CMakeFiles/Makefile2:1636: recipe for target 'lib/asan/CMakeFiles/asan.dir/rule' failed
Makefile:632: recipe for target 'asan' failed

--- stderr
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cc: In functionvoid __ubsan::HandleCFIBadType(__ubsan::CFICheckFailData*, __ubsan::ValueHandle, bool, __ubsan::ReportOptions)’:
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/ubsan/ubsan_handlers_cxx.cc:111:15: warning: ‘CheckKindStrmay be used uninitialized in this function [-Wmaybe-uninitialized]
   const char *CheckKindStr;
               ^~~~~~~~~~~~
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc: In functionint __sanitizer::TracerThread(void*)’:
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cc:278:22: error: aggregatesigaltstack handler_stackhas incomplete type and cannot be defined
   struct sigaltstack handler_stack;
                      ^~~~~~~~~~~~~
make[3]: *** [lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/sanitizer_stoptheworld_linux_libcdep.cc.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc: In function__sanitizer::fd_t __sanitizer::OpenFile(const char*, __sanitizer::FileAccessMode, __sanitizer::error_t*)’:
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/sanitizer_common/sanitizer_posix.cc:215:27: warning: ‘flagsmay be used uninitialized in this function [-Wmaybe-uninitialized]
   fd_t res = internal_open(filename, flags, 0660);
              ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/asan_interceptors.cc:265:0:
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc: In function__sanitizer::uptr __interceptor_ptrace(int, int, void*, void*)’:
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2810:21: warning: ‘local_iovec.__sanitizer::__sanitizer_iovec::iov_lenmay be used uninitialized in this function [-Wmaybe-uninitialized]
   __sanitizer_iovec local_iovec;
                     ^~~~~~~~~~~
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/asan_interceptors.cc:59:10: warning: ‘local_iovec.__sanitizer::__sanitizer_iovec::iov_basemay be used uninitialized in this function [-Wmaybe-uninitialized]
     uptr __offset = (uptr)(offset);                                     \
          ^~~~~~~~
In file included from /home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/asan_interceptors.cc:265:0:
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2810:21: note: ‘local_iovec.__sanitizer::__sanitizer_iovec::iov_basewas declared here
   __sanitizer_iovec local_iovec;
                     ^~~~~~~~~~~
In file included from /home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/asan_interceptors.cc:265:0:
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc: In function__sanitizer::uptr __interceptor_ptrace(int, int, void*, void*)’:
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2810:21: warning: ‘local_iovec.__sanitizer::__sanitizer_iovec::iov_lenmay be used uninitialized in this function [-Wmaybe-uninitialized]
   __sanitizer_iovec local_iovec;
                     ^~~~~~~~~~~
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/asan_interceptors.cc:59:10: warning: ‘local_iovec.__sanitizer::__sanitizer_iovec::iov_basemay be used uninitialized in this function [-Wmaybe-uninitialized]
     uptr __offset = (uptr)(offset);                                     \
          ^~~~~~~~
In file included from /home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/asan_interceptors.cc:265:0:
/home/simon/rust/src/libcompiler_builtins/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2810:21: note: ‘local_iovec.__sanitizer::__sanitizer_iovec::iov_basewas declared here
   __sanitizer_iovec local_iovec;
                     ^~~~~~~~~~~
make[1]: *** [lib/asan/CMakeFiles/asan.dir/rule] Error 2
make: *** [asan] Error 2
thread 'main' panicked at '
command did not execute successfully, got: exit code: 2

build script failed, must exit now', /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.26/src/lib.rs:599:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

thread 'main' panicked at 'command did not execute successfully: "/home/simon/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "8" "--release" "--features" "panic-unwind jemalloc backtrace profiler" "--manifest-path" "/home/simon/rust/src/libstd/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101', src/bootstrap/compile.rs:882:8

@gnzlbg
Copy link
Contributor

gnzlbg commented Nov 27, 2017

The comment in .travis.yml still says that alt-builds don't have assertions enabled, but it is actually the other way around 😆

@kennytm
Copy link
Member

kennytm commented Nov 27, 2017

@gnzlbg Well PRs welcomed 😅

@SimonSapin
Copy link
Contributor Author

#46330

@michaelwoerister
Copy link
Member

@SimonSapin that's a comment you have to dereference twice in order to get to the actual content :D

@gnzlbg
Copy link
Contributor

gnzlbg commented Nov 28, 2017

@michaelwoerister dammit michael! I tried dereferencing it twice and now I am trapped in a loop!

kennytm added a commit to kennytm/rust that referenced this pull request Nov 28, 2017
Introduced a new src/etc/cat-and-grep.sh script (called in run-make as
$(CGREP)), which prints the input and do a grep simultaneously. This is
mainly used to debug spurious failures in run-make, such as the sanitizer
error in rust-lang#45810, as well as real errors such as rust-lang#46126.
bors added a commit that referenced this pull request Nov 28, 2017
Replace most call to grep in run-make by a script that cat the input.

Introduced a new `src/etc/cat-and-grep.sh` script (called in run-make as `$(CGREP)`), which prints the input and do a grep simultaneously. This is mainly used to debug spurious failures in run-make, such as the spurious error in #45810, as well as real errors such as #46126.

(cc #40713)

Some `grep` still remains, mainly the `grep -c` calls that count the number of matches and print the result to stdout.
kennytm added a commit to kennytm/rust that referenced this pull request Nov 29, 2017
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Oct 2, 2019
…:nightly); r=nox

With rust-lang/rust#45810, normal Nightly now has LLVM assertions disabled.

This allows us to entirely stop relying on private/unstable Rust CI artifacts being and remaining available: https://internals.rust-lang.org/t/public-stable-rust-services/6072

Source-Repo: https://github.com/servo/servo
Source-Revision: 856dc3c90ab920880e0bdca171720f37e40dd597

UltraBlame original commit: 6406e73a24bca7b3355ff438c283fe0bd20afdaf
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Oct 2, 2019
…:nightly); r=nox

With rust-lang/rust#45810, normal Nightly now has LLVM assertions disabled.

This allows us to entirely stop relying on private/unstable Rust CI artifacts being and remaining available: https://internals.rust-lang.org/t/public-stable-rust-services/6072

Source-Repo: https://github.com/servo/servo
Source-Revision: 856dc3c90ab920880e0bdca171720f37e40dd597

UltraBlame original commit: 6406e73a24bca7b3355ff438c283fe0bd20afdaf
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Oct 2, 2019
…:nightly); r=nox

With rust-lang/rust#45810, normal Nightly now has LLVM assertions disabled.

This allows us to entirely stop relying on private/unstable Rust CI artifacts being and remaining available: https://internals.rust-lang.org/t/public-stable-rust-services/6072

Source-Repo: https://github.com/servo/servo
Source-Revision: 856dc3c90ab920880e0bdca171720f37e40dd597

UltraBlame original commit: 6406e73a24bca7b3355ff438c283fe0bd20afdaf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.