Comments (46)
fun fact: over the last month miri has gotten faster by a factor of two. At least the rustc test suite is finished twice as fast (number of tests went up! not down). This might either be due to improvements in rustc or due to improvements in miri.
from miri.
see in first post for frequently updating file
from miri.
I think I broke it in 8b8c743
fixed it, report and PR coming in around an hour.
from miri.
updated log
from miri.
updated log.
from miri.
@gnzlbg Yeah, I refer to that idea as #[cfg(const)]
. I guess bring it up again once we have RFCs for the more advanced const features Miri will enable.
from miri.
I'm running this now with full std mir enabled. We seem to have some previously unknown issues. But at least "no mir" errors have gone down to 2.
from miri.
Is there any way to run miri on the tests (#[test]
) embedded in e.g. libstd? Most of the functional tests are actually such embedded tests, not run-pass tests.
from miri.
I have implementations for atomic_load
, atomic_store
, and atomic_xadd_relaxed
which don't really do anything atomic, but it shouldn't matter when we don't have actual parallelism. A few others like the relaxed/non-relaxed variants and volatile_{load,store}
should be just as easy.
I'll submit them soon and see how the test results change.
from miri.
I implemented the missing non atomic*
intrinsics. Rustc seriously needs more tests, every intrinsic should at least have a run-pass test...
from miri.
use of fn(usize) -> Foo as fn(usize) -> u32
use of fn(&isize) -> Option<&isize> as fn(&isize) -> &isize
These are used when working with ffi... Should we support these cases?
I mean, any &isize
can be transmuted to Option<&isize>
and will be perfectly fine. Afaik this is guaranteed.
from miri.
to pass more tests we need to implement panic and print, some minor bugs are left, but these make up most of our failed tests.
from miri.
@oli-obk Any chance you could gist the entire test output? Assuming it contains both names and messages, it would let people like me to idly rummage through some of the maybe-UB tests.
from miri.
https://github.com/rust-lang/rust/blob/master/src/test/run-pass/mir_raw_fat_ptr.rs#L129 compares pointers into different allocs ( same in raw_fat_ptr.rs and mir_raw_fat_ptr.rs)
from miri.
I believe we could impose an ordering between unrelated allocations, but it wouldn't really be based on anything (it would just have to be deterministic).
I've seen a C interpreter that essentially has an arbitrary deterministic ordering, if I recall correctly.
from miri.
@solson Not in CTFE mode, though, right?
from miri.
@eddyb No, even in CTFE mode, if we can guarantee determinism.
from miri.
That's gonna expose some internals and differ depending on the mir optimizations that are run before evaluation.
from miri.
@solson If that determinism depends on the order things were evaluated in, that's not deterministic enough. It should be impossible for constant evaluation to observe any past interactions.
So maybe it'd make sense for "stack memory"? Not worth risking it though.
from miri.
It doesn't really expose anything. It's fine if it differs, so long as it runs the same given the same inputs (sources, flags, etc).
from miri.
@eddyb Yeah, it wouldn't work if you re-use the same uncleared Memory
for different runs in some manner.
from miri.
I agree it sounds too risky for CTFE now.
from miri.
so long as it runs the same given the same inputs
Nope, that's not enough, the "inputs" are the MIR to evaluate and its generic parameters, not the whole compilation. I've described how getting this wrong even one bit can impact coherence and thus soundness.
Presumably there'd be some global Memory
to cache results but its state should not be observable.
from miri.
I updated the top post with a list of the missing MIRs and a list of all panics happening inside miri. I also attached an updated raw output file.
from miri.
@oli-obk Can you re-run and update the OP? I was having some odd problems running it, but I can investigate stuff based on your results for now.
from miri.
sure
from miri.
There are a number of "invalid enum discriminant value read" results in your log that I can't reproduce. When I run those tests, they succeed.
from miri.
our rustc versions and/or test suite may differ due to different checkouts. My checkout is from February 2nd. My rustc is rustc 1.16.0-nightly (24055d0f2 2017-01-31)
from miri.
rustc 1.17.0-nightly (ea7a6486a 2017-02-04) with the latest checkout here. Maybe your packed struct PR a few days ago fixed things?
from miri.
I'll investigate
from miri.
ok, so updating rustc and the checkout fixed these bugs, so it must be something rustc changed that fixed it and not us, because I used the same miri code base. Regenerating log...
from miri.
I investigated "mir_adt_construction.rs" which failed with "tried to access memory with alignment 1, but alignment 8 is required".
It reduces to:
#[repr(packed)]
#[derive(PartialEq, Debug)]
struct Pakd {
a: u64,
b: u32,
c: u16,
d: u8,
e: ()
}
fn test2() -> Pakd {
Pakd { a: 42, b: 42, c: 42, d: 42, e: () }
}
fn main() {
assert_eq!(test2(), Pakd { a: 42, b: 42, c: 42, d: 42, e: () });
}
I figure that this is actually a problem with the test, not Miri. The derived PartialEq
implementation will access the packed field inappropriately (through references). Once rustc makes taking references to unaligned packed fields unsafe, then the derive(PartialEq)
itself will fail to compile due to unsafe code.
from miri.
We should figure out which of the "no MIR" errors are in fact assertions we are hitting.
from miri.
@oli-obk Good point, I forgot that those could be test failures.
from miri.
every NO MIR FOR ...panic...
is a test failure.
17 NO MIR FOR `std::panicking::rust_panic_with_hook`
7 NO MIR FOR `std::rt::begin_panic_fmt`
7 NO MIR FOR `std::panicking::panicking`
some of these are useless... like a test testing --test
compileflag, which we simply ignore and try to run the main
function, which simply panics.
rerunning after 1 > -1
is true again, since that fixes a few of those.
from miri.
Is there a plan for supporting inline assembly?
from miri.
@gnzlbg No.
from miri.
So there will never be a way to work around that?
from miri.
If rust code could detect that is being run at compile-time, and branch on it, it could provide a different implementation of some functionality without features that miri will probably never understand (like inline assembly, SIMD intrinsics, llvm intrinsics, etc).
from miri.
Cool! Something like #[cfg(const)]
would be a really pragmatic hack!
from miri.
@oli-obk It'd be nice to split the "error" count in the OP into true errors and "unsupported", so things like lack of threading don't inflate the error count. I'd also prefer to have them in separate lists if possible.
from miri.
#[cfg(const)]
is syntactical whereas this needs to decide based on what executes it
from miri.
Good point, it wouldn't actually use cfg
.
from miri.
@oli-obk If you look at your 2 "MIR not found" errors, I'm pretty sure the ::::
is from extern {...}
, so these are most likely FFI.
from miri.
hmm... I think I implemented this in cargo miri
. But I'm not sure how to run that inside the rustc build system.
from miri.
Also see https://github.com/RalfJung/miri-test-libstd/issues/1
from miri.
Related Issues (20)
- Running `Cargo miri test` on `cargo`, an error occurred HOT 6
- Massive slowdown caused by stacked borrows on code involving raw pointers + UnsafeCell HOT 6
- Programs that cast function pointers have escalating memory use HOT 1
- Support `SystemTime` with enabled isolation HOT 4
- Implement pipe/pipe2 HOT 1
- pthreads synchronization primitives: detect mutex/rwlock/... being moved to a different location HOT 8
- FFI implementation libc getuid on Linux HOT 2
- False positive deadlock with `pollster` and async HOT 2
- Support miri-specific entry point / start function for no-std binaries
- Miri can't call foreign function `mi_malloc_aligned` on OS `linux` HOT 1
- Tree-borrows false positive with `iter::Extend`? HOT 5
- offset_from "same allocation" check is confused by int-to-ptr casts HOT 3
- Are unclosed file descriptors a memory leak? HOT 3
- Project idea: strongly typed file descriptor integers and deduplication of various checks around them HOT 4
- false positive with SB+TB: "Shifting" of a value HOT 6
- `cargo miri test` fails without `RUSTC` env var HOT 3
- Undefined behavior from `poll_fn` + `futures::join!` / `std::future::join!` HOT 11
- Tail calls end protectors too early HOT 2
- !Send Future violates stacked borrow rules HOT 10
- Implicit reborrows do not cause writes HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from miri.