bors [Thu, 3 Jun 2021 15:42:41 +0000 (15:42 +0000)]
Auto merge of #1824 - Pointerbender:strings-test, r=RalfJung
added a strings.rs regression test case for potential future UB
This PR adds a regression test for the aliasing rules of a `Unique<T>` pointer.
At the time of writing this test case, Miri does not treat `Unique<T>`
pointers as a special case, these are treated like any other raw pointer.
However, there are existing Github issues which may lead to `Unique<T>`
becoming a special case through asserting unique ownership over the pointee:
- https://github.com/rust-lang/unsafe-code-guidelines/issues/258
- https://github.com/rust-lang/unsafe-code-guidelines/issues/262
In the new test case, the calls to `String::remove` and `String::insert[_str]` follow
code paths that would trigger undefined behavior in case `Unique<T>`
would ever assert semantic ownership over the pointee. Internally,
these methods call `self.vec.as_ptr()` and `self.vec.as_mut_ptr()` on
the vector of bytes that are backing the `String`. That `Vec<u8>` holds a
`Unique<u8>` internally. The second call to `Vec::as_mut_ptr(&mut self)`
would then invalidate the pointers derived from `Vec::as_ptr(&self)`.
Note that as long as `Unique<T>` is treated like any other raw pointer,
this test case should pass. It is merely here as a canary test for
potential future undefined behavior.
bors [Thu, 3 Jun 2021 08:52:57 +0000 (08:52 +0000)]
Auto merge of #1816 - Pointerbender:slices-tests, r=RalfJung
regression tests for pointer invalidation in core library slice methods
A fix for a pointer invalidation bug in `<[T]>::copy_within` has [landed](https://github.com/rust-lang/rust/pull/85610) on the Rust master branch. This PR updates the `rust-version` file to the latest master commit hash and adds extra tests to the Miri test suite to ensure that regressions of this type of bug can be detected for various slice methods with the `-Zmiri-track-raw-pointers` flag.
I took the liberty of adding 2 extra `#![feature]` attributes at the top of `slices.rs`, since there already was one unstable feature. I hope this is okay :smile:
One thing I noticed when running the entire Miri test suite with `MIRIFLAGS="-Zmiri-track-raw-pointers" ./miri test` is that there are currently failing tests on the master branch:
test result: FAILED. 199 passed; 6 failed; 1 ignored; 0 measured; 0 filtered out; finished in 12.95s
```
These failures were not fixed in this PR and already existed prior to this PR. I haven't investigated these yet, but am interested in helping out if possible!
bors [Sun, 30 May 2021 15:14:23 +0000 (15:14 +0000)]
Auto merge of #1791 - Aaron1011:measureme, r=RalfJung
Add `measureme` integration for profiling the interpreted program
This PR uses the `measureme` crate to profile the call stack of the
program being interpreted by Miri. This is accomplished by starting a
measureme 'event' when we enter a function call, and ending the event
when we exit the call. The `measureme` tooling can be used to produce a
call stack from the generated profile data.
Limitations:
* We currently record every single entry/exit. This might generate very
large profile outputs for programs with a large number of function
calls. In follow-up work, we might want to explore sampling (e.g. only
recording every N function calls).
* This does not integrate very well with Miri's concurrency support.
Each event we record starts when we push a frame, and ends when we pop
a frame. As a result, the timing recorded for a particular frame will include all of the work Miri does before that frame completes, including executing another thread.
The `measureme` integration is off by default, and must be enabled via
`-Zmiri-measureme=<output_name>`
Aaron Hill [Sat, 8 May 2021 16:20:51 +0000 (12:20 -0400)]
Add `measureme` integration for profiling the interpreted program
This PR uses the `measureme` crate to profile the call stack of the
program being interpreted by Miri. This is accomplished by starting a
measureme 'event' when we enter a function call, and ending the event
when we exit the call. The `measureme` tooling can be used to produce a
call stack from the generated profile data.
Limitations:
* We currently record every single entry/exit. This might generate very
large profile outputs for programs with a large number of function
calls. In follow-up work, we might want to explore sampling (e.g. only
recording every N function calls).
* This does not integrate very well with Miri's concurrency support.
Each event we record starts when we push a frame, and ends when we pop
a frame. As a result, switching between virtual threads will cause
events from different threads to be interleaved. Additionally, the
recorded for a particular frame will include all of the work Miri does
before that frame completes, including executing another thread.
The `measureme` integration is off by default, and must be enabled via
`-Zmiri-measureme=<output_name>`
bors [Sat, 22 May 2021 12:56:51 +0000 (12:56 +0000)]
Auto merge of #1811 - RalfJung:less-rc, r=RalfJung
get rid of some `Rc`
Now that the memory access hooks get references to `MemoryExtra`, we can avoid refcounting for the global state of Stacked Borrows and the data race detector.
`@semarie` this should fix your problem... but I think any version of Miri actually shipped to users should have the proper git version information embedded, so I am not sure if this is the right fix. How do you do this for rustc proper? Even stable builds usually have a git version:
```
$ rustc +stable --version
rustc 1.51.0 (2fd73fabe 2021-03-23)
```
bors [Wed, 12 May 2021 14:57:42 +0000 (14:57 +0000)]
Auto merge of #1794 - cbeuw:83813, r=RalfJung
Sync with rustc_span changes
rust-lang/rust#83813 made some changes to SourceMap and RealFileName. Now to get a string from a `rustc_span::FileName`, we need to specify if we would like the local filesystem path or remapped path via `--remap-path-prefix`. There seems to be only one place in miri that requires change.
bors [Tue, 4 May 2021 08:27:00 +0000 (08:27 +0000)]
Auto merge of #1788 - hyd-dev:rustup, r=RalfJung
`encountered a NULL reference` -> `encountered a null reference`
It's changed from "NULL" to "null" (probably by rust-lang/rust#84842) in `rustc`, and causing some test failures:
https://github.com/rust-lang/miri/runs/2498333632#step:8:640
bors [Mon, 3 May 2021 17:32:50 +0000 (17:32 +0000)]
Auto merge of #1785 - Smittyvb:fast-math-ub, r=RalfJung
Throw UB if f*_fast intrinsic called with non-finite value
Calling these intrinsics with non-finite values is undefined behaviour, since they result in `f*` intrinsics in LLVM with the `fast` flag, and `fast` math on non-finite values results in `poison` values. (technically LLVM only considers it UB upon _using_ the value, but that shouldn't make much of a difference)
projects / rust.git / log