Data race spans #2646

saethlin · 2022-11-04T00:01:42Z

This adds output to data race errors very similar to the spans we emit for Stacked Borrows errors. For example, from our test suite:

help: The Atomic Load on thread `<unnamed>` is here
  --> tests/fail/data_race/atomic_read_na_write_race1.rs:23:13
   |
23 | ...   (&*c.0).load(Ordering::SeqCst) //~ ERROR: Data race detected between Atomic Load on thread `<unnamed>` and Write o...
   |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: The Write on thread `<unnamed>` is here
  --> tests/fail/data_race/atomic_read_na_write_race1.rs:19:13
   |
19 |             *(c.0 as *mut usize) = 32;
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^```

Because of #2647 this comes without a perf regression, according to our benchmarks.

RalfJung · 2022-11-04T17:52:07Z

I assume this is intended to fix #2205 ?

(Since it is marked as a draft, I'll not put it in my queue for now.)

bors · 2022-11-13T12:58:19Z

☔ The latest upstream changes (presumably #2663) made this pull request unmergeable. Please resolve the merge conflicts.

RalfJung · 2022-11-23T14:31:48Z

@rustbot author

Track local frames incrementally during execution #2646 currently introduces a performance regression. This change removes that regression, and provides a minor perf improvement. The existing lazy strategy for tracking the span we want to display is as efficient as it is only because we often create a `CurrentSpan` then never call `.get()`. Most of the calls to the `before_memory_read` and `before_memory_write` hooks do not create any event that we store in `AllocHistory`. But data races are totally different, any memory read or write may race, so every call to those hooks needs to access to the current local span. So this changes to a strategy where we update some state in a `Thread` and `FrameExtra` incrementally, upon entering and existing each function call. Before: ``` Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/backtraces/Cargo.toml Time (mean ± σ): 5.532 s ± 0.022 s [User: 5.444 s, System: 0.073 s] Range (min … max): 5.516 s … 5.569 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/mse/Cargo.toml Time (mean ± σ): 831.4 ms ± 3.0 ms [User: 783.8 ms, System: 46.7 ms] Range (min … max): 828.7 ms … 836.1 ms 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde1/Cargo.toml Time (mean ± σ): 1.975 s ± 0.021 s [User: 1.914 s, System: 0.059 s] Range (min … max): 1.939 s … 1.990 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde2/Cargo.toml Time (mean ± σ): 4.060 s ± 0.051 s [User: 3.983 s, System: 0.071 s] Range (min … max): 3.972 s … 4.100 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/slice-get-unchecked/Cargo.toml Time (mean ± σ): 784.9 ms ± 8.2 ms [User: 746.5 ms, System: 37.7 ms] Range (min … max): 772.9 ms … 793.3 ms 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/unicode/Cargo.toml Time (mean ± σ): 1.679 s ± 0.006 s [User: 1.623 s, System: 0.055 s] Range (min … max): 1.673 s … 1.687 s 5 runs ``` After: ``` Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/backtraces/Cargo.toml Time (mean ± σ): 5.330 s ± 0.037 s [User: 5.232 s, System: 0.084 s] Range (min … max): 5.280 s … 5.383 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/mse/Cargo.toml Time (mean ± σ): 818.9 ms ± 3.7 ms [User: 776.8 ms, System: 41.3 ms] Range (min … max): 813.5 ms … 822.5 ms 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde1/Cargo.toml Time (mean ± σ): 1.927 s ± 0.011 s [User: 1.864 s, System: 0.061 s] Range (min … max): 1.917 s … 1.945 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde2/Cargo.toml Time (mean ± σ): 3.974 s ± 0.020 s [User: 3.893 s, System: 0.076 s] Range (min … max): 3.956 s … 4.004 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/slice-get-unchecked/Cargo.toml Time (mean ± σ): 780.0 ms ± 5.3 ms [User: 740.3 ms, System: 39.0 ms] Range (min … max): 771.2 ms … 784.5 ms 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/unicode/Cargo.toml Time (mean ± σ): 1.643 s ± 0.007 s [User: 1.584 s, System: 0.058 s] Range (min … max): 1.635 s … 1.654 s 5 runs ``` (This change is marginal, but the point is that it avoids a much more significant regression)

Track local frames incrementally during execution rust-lang/miri#2646 currently introduces a performance regression. This change removes that regression, and provides a minor perf improvement. The existing lazy strategy for tracking the span we want to display is as efficient as it is only because we often create a `CurrentSpan` then never call `.get()`. Most of the calls to the `before_memory_read` and `before_memory_write` hooks do not create any event that we store in `AllocHistory`. But data races are totally different, any memory read or write may race, so every call to those hooks needs to access to the current local span. So this changes to a strategy where we update some state in a `Thread` and `FrameExtra` incrementally, upon entering and existing each function call. Before: ``` Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/backtraces/Cargo.toml Time (mean ± σ): 5.532 s ± 0.022 s [User: 5.444 s, System: 0.073 s] Range (min … max): 5.516 s … 5.569 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/mse/Cargo.toml Time (mean ± σ): 831.4 ms ± 3.0 ms [User: 783.8 ms, System: 46.7 ms] Range (min … max): 828.7 ms … 836.1 ms 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde1/Cargo.toml Time (mean ± σ): 1.975 s ± 0.021 s [User: 1.914 s, System: 0.059 s] Range (min … max): 1.939 s … 1.990 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde2/Cargo.toml Time (mean ± σ): 4.060 s ± 0.051 s [User: 3.983 s, System: 0.071 s] Range (min … max): 3.972 s … 4.100 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/slice-get-unchecked/Cargo.toml Time (mean ± σ): 784.9 ms ± 8.2 ms [User: 746.5 ms, System: 37.7 ms] Range (min … max): 772.9 ms … 793.3 ms 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/unicode/Cargo.toml Time (mean ± σ): 1.679 s ± 0.006 s [User: 1.623 s, System: 0.055 s] Range (min … max): 1.673 s … 1.687 s 5 runs ``` After: ``` Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/backtraces/Cargo.toml Time (mean ± σ): 5.330 s ± 0.037 s [User: 5.232 s, System: 0.084 s] Range (min … max): 5.280 s … 5.383 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/mse/Cargo.toml Time (mean ± σ): 818.9 ms ± 3.7 ms [User: 776.8 ms, System: 41.3 ms] Range (min … max): 813.5 ms … 822.5 ms 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde1/Cargo.toml Time (mean ± σ): 1.927 s ± 0.011 s [User: 1.864 s, System: 0.061 s] Range (min … max): 1.917 s … 1.945 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde2/Cargo.toml Time (mean ± σ): 3.974 s ± 0.020 s [User: 3.893 s, System: 0.076 s] Range (min … max): 3.956 s … 4.004 s 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/slice-get-unchecked/Cargo.toml Time (mean ± σ): 780.0 ms ± 5.3 ms [User: 740.3 ms, System: 39.0 ms] Range (min … max): 771.2 ms … 784.5 ms 5 runs Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/unicode/Cargo.toml Time (mean ± σ): 1.643 s ± 0.007 s [User: 1.584 s, System: 0.058 s] Range (min … max): 1.635 s … 1.654 s 5 runs ``` (This change is marginal, but the point is that it avoids a much more significant regression)

saethlin · 2022-12-16T16:39:20Z

@rustbot ready

src/concurrency/vector_clock.rs

oli-obk · 2022-12-20T14:34:11Z

src/concurrency/vector_clock.rs

+    }
+}
+
+impl IndexMut<VectorIdx> for VClock {


Side-note: we could probably use https://doc.rust-lang.org/nightly/nightly-rustc/rustc_index/vec/struct.IndexVec.html for VClock and https://doc.rust-lang.org/nightly/nightly-rustc/rustc_index/macro.newtype_index.html for VectorIdx

Hm, IndexVec just wraps a Vec and currently this uses SmallVec, and this PR is already messing with the inline capacity. There are ambient concerns about the data race detector overhead: #2716 #1689 which in my experience are not backed up by profiling, but I still think the prudent thing to do is adjust one thing at a time here. Happy to look into this in a separate PR.

Makes sense

src/concurrency/vector_clock.rs

tests/fail/data_race/atomic_write_na_read_race2.stderr

oli-obk · 2022-12-21T07:26:32Z

src/concurrency/vector_clock.rs

-/// The type of the time-stamps recorded in the data-race detector
-/// set to a type of unsigned integer
-pub type VTimestamp = u32;
+/// The time-stamps recorded in the data-race detector consist of both


Everything starting at consists should be on the fields. Internal docs use the flag to generate docs for private items

This comment seems to be still open.

oli-obk

r=me after a doc nit

src/concurrency/data_race.rs

RalfJung · 2022-12-21T10:24:28Z

src/concurrency/init_once.rs

@@ -172,7 +173,7 @@ pub trait EvalContextExt<'mir, 'tcx: 'mir>: crate::MiriInterpCxExt<'mir, 'tcx> {

        // Each complete happens-before the end of the wait
        if let Some(data_race) = &this.machine.data_race {
-            data_race.validate_lock_release(&mut init_once.data_race, current_thread);
+            data_race.validate_lock_release(&mut init_once.data_race, current_thread, current_span);


Would it make sense to move the current_span calls behind the fn call? That seems nicer than putting the burden on all callers. Basically instead of passing current_thread and current_span it could pass &Machine?

EDIT: Ah, that doesn't work since it overlaps with data_race. Hm... I guess we can go ahead with separate arguments for now, but if you have a nice idea for how to avoid having to pass so many arguments, that would be great.

src/concurrency/vector_clock.rs

src/diagnostics.rs

RalfJung · 2022-12-21T10:30:55Z

tests/fail/data_race/alloc_read_race.stderr

+   |
+LL | ...   *pointer.load(Ordering::Relaxed)
+   |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+help: The Allocate on thread `<unnamed>` is here


Nit: is "is" the right verb? One of them happened in the past. Do we know which one? Can we make the message "Earlier, the X on thread Y happened here" and "Now, the X' on thread Y' happened here"? In fact isn't the latter span redundant with the main error span?

Hah I was also not sure what words to use here. This is a data race, so strictly does it make any sense to say that one of these operations happens before the other? They happen in a particular order in the interpreter, but should diagnostics be commenting on the interpreter or the program semantics (or lack thereof)?

I chose present tense because I imagine this diagnostic as a response to the current user experience, where someone would rightfully ask "But Miri, where is the read/write/allocate/deallocate?" so now Miri says "The read/write/allocate/deallocate is here"

(As I describe this I realize it is not consistent with how I worded the Stacked Borrows diagnostics. Ah well.)

With vector clocks, there could actually be considerate amounts of "real time" between the two operations, even in an observable way. But you also have a point.

What about the fact that one of these two spans is always redundant since it is the same as where the error points? I think it'd be better to just say "the other access was over there" or so?

Yeah, I've tried to reduce the duplication here, but I feel backed into a corner again by the limited diagnostics API. Doesn't change the fact that this is still much better than before.

This seems potentially confusing, since after the help we have a backtrace that attaches to the "main span", not the "other access span". I think that's why I think it is good to say something about the "earlier conflicting access". Also if both accesses are of the same kind, saying "the Write" is not very informative.

So what about

error: Undefined Behavior: Data race detected between (1) Atomic Store on thread `<unnamed>` and (2) Read on thread `<unnamed>` at ALLOC. Access (2) just happened here --> $DIR/atomic_write_na_read_race1.rs:LL:CC | LL | *atomic_ref.get_mut() | ^^^^^^^^^^^^^^^^^^^^^ | help: and access (1) occurred earlier here --> $DIR/atomic_write_na_read_race1.rs:LL:CC | LL | atomic_ref.store(32, Ordering::SeqCst) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: BACKTRACE: = note: inside closure at $DIR/atomic_write_na_read_race1.rs:LL:CC

Yeah it is annoying that the same text is repeated for the error title and label -- that would be #2200, which will be very annoying work since all the ui tests will need adjustment.

I agree there is potential for confusion with the backtrace. I often find the Stacked Borrows errors a bit visually confusing, and have often wanted some other way to format all this information. I'll try to keep an eye on how this plays out.

I like this numbering strategy overall, I'm just not sure about calling these an "access". That word has a particular meaning in Stacked Borrows, and feel like calling an allocation or deallocation an access might be confusing to newcomers (even though it is technically correct to use the word). I think we can just drop the word without loss of clarity?

Also it occurs to me that we're now comparing a "local" span with the topmost frame, so things could look a bit odd if the race occurs through a standard library function that isn't #[track_caller]. I can't find any examples of this, so it may be that the way people write data races, this just isn't a concern. Just mentioning this so you're aware of it, I think we shouldn't cook up a solution until we have a real example.

Also it occurs to me that we're now comparing a "local" span with the topmost frame, so things could look a bit odd if the race occurs through a standard library function that isn't #[track_caller].

The main backtrace will also skip track_caller frames by default so I think one needs to pass -Zmiri-backtrace=full to get anything weird?

I pushed an attempt to clarify the backtrace situation a bit. What do you think?

I think the clarification is good. It's a marginal improvement, but an improvement.

Here is an example of a program that produces the flavor of weird output I'm referring to:

use std::sync::atomic::AtomicPtr; fn main() { let mut v: Vec<i32> = Vec::with_capacity(2); let ptr = AtomicPtr::new(v.as_mut_ptr()); let handle = std::thread::spawn(move || { let mut v = unsafe { Vec::from_raw_parts(ptr.into_inner(), 0, 2) }; v.push(0); }); v.push(0); let _ = handle.join(); }

error: Undefined Behavior: Data race detected between (1) Write on thread `main` and (2) Write on thread `<unnamed>` at alloc1617. (2) just happened here --> /home/ben/.rustup/toolchains/miri/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs:1839:13 | 1839 | ptr::write(end, value); | ^^^^^^^^^^^^^^^^^^^^^^ Data race detected between (1) Write on thread `main` and (2) Write on thread `<unnamed>` at alloc1617. (2) just happened here | help: and (1) occurred earlier here --> demo.rs:9:5 | 9 | v.push(2); | ^^^^^^^^^ = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information = note: BACKTRACE (of the first span): = note: inside `std::vec::Vec::<i32>::push` at /home/ben/.rustup/toolchains/miri/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs:1839:13: 1839:35 note: inside closure --> demo.rs:7:9 | 7 | v.push(1); | ^^^^^^^^^

The wording of our diagnostic pretty clearly asks the user to compare the topmost span of the backtrace and the first help span, but the topmost span can be dislocated from the user code by a fair bit if it is buried inside a standard library data structure or algorithm. For example, if a data race is triggered by the PartialOrd impl used in the depths of slice::sort. (as I write this I'm realizing I could have cooked up a more extreme example, ah well...)

Oh I see. Yeah... I think this PR here is still an improvement, feel free to file an issue to track this problem and possible ideas for how to fix it.

RalfJung · 2022-12-21T10:46:58Z

@saethlin could you do benchmarks with -Zmiri-disable-stacked-borrows -Zmiri-disable-validation so that we can an idea for how expensive this is?

saethlin · 2022-12-22T02:19:23Z

Before:

Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/backtraces/Cargo.toml
  Time (mean ± σ):      2.262 s ±  0.005 s    [User: 2.204 s, System: 0.054 s]
  Range (min … max):    2.256 s …  2.270 s    5 runs
 
Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/mse/Cargo.toml
  Time (mean ± σ):     389.0 ms ±   4.6 ms    [User: 351.8 ms, System: 36.8 ms]
  Range (min … max):   383.3 ms … 394.1 ms    7 runs
 
Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde1/Cargo.toml
  Time (mean ± σ):     930.7 ms ±   6.6 ms    [User: 882.4 ms, System: 47.3 ms]
  Range (min … max):   924.3 ms … 940.7 ms    5 runs
 
Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde2/Cargo.toml
  Time (mean ± σ):      1.844 s ±  0.033 s    [User: 1.795 s, System: 0.047 s]
  Range (min … max):    1.812 s …  1.885 s    5 runs
 
Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/slice-get-unchecked/Cargo.toml
  Time (mean ± σ):     322.3 ms ±   4.2 ms    [User: 282.1 ms, System: 40.0 ms]
  Range (min … max):   313.0 ms … 326.0 ms    9 runs
 
Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/unicode/Cargo.toml
  Time (mean ± σ):     717.5 ms ±   2.1 ms    [User: 681.5 ms, System: 35.4 ms]
  Range (min … max):   714.5 ms … 720.2 ms    5 runs

After:

Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/backtraces/Cargo.toml
  Time (mean ± σ):      2.275 s ±  0.038 s    [User: 2.201 s, System: 0.057 s]
  Range (min … max):    2.245 s …  2.341 s    5 runs
  
Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/mse/Cargo.toml
  Time (mean ± σ):     393.9 ms ±   1.2 ms    [User: 360.0 ms, System: 33.6 ms]
  Range (min … max):   392.4 ms … 396.1 ms    7 runs
 
Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde1/Cargo.toml
  Time (mean ± σ):     933.1 ms ±   3.2 ms    [User: 888.6 ms, System: 43.6 ms]
  Range (min … max):   927.8 ms … 935.5 ms    5 runs
 
Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/serde2/Cargo.toml
  Time (mean ± σ):      1.909 s ±  0.006 s    [User: 1.851 s, System: 0.056 s]
  Range (min … max):    1.899 s …  1.916 s    5 runs
 
Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/slice-get-unchecked/Cargo.toml
  Time (mean ± σ):     325.8 ms ±   2.0 ms    [User: 287.1 ms, System: 38.5 ms]
  Range (min … max):   323.5 ms … 329.6 ms    9 runs
 
Benchmark 1: cargo +miri miri run --manifest-path /home/ben/miri/bench-cargo-miri/unicode/Cargo.toml
  Time (mean ± σ):     715.4 ms ±   3.4 ms    [User: 672.1 ms, System: 42.6 ms]
  Range (min … max):   711.0 ms … 720.2 ms    5 runs

This is about the size of the effect I expected.

…ambiguity

RalfJung · 2022-12-23T14:42:10Z

tests/fail/data_race/atomic_read_na_write_race1.stderr

   |
+help: and (2) occurred earlier here


So (2) happened before (1) in execution order. That seems confusing? I had deliberately swapped them in my proposal.

🤦 I was so sure I was following your proposal

…ter sees them

RalfJung · 2022-12-24T08:13:26Z

@bors r+

bors · 2022-12-24T08:13:28Z

📌 Commit 60a100a has been approved by RalfJung

It is now in the queue for this repository.

bors · 2022-12-24T08:13:34Z

⌛ Testing commit 60a100a with merge 4ec960f...

bors · 2022-12-24T08:39:50Z

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 4ec960f to master...

update Miri Noteworthy PRs: - rust-lang/miri#2357 - rust-lang/miri#2646 - rust-lang/miri#2718 - rust-lang/miri#2721 - rust-lang/miri#2725

update Miri Noteworthy PRs: - rust-lang#2357 - rust-lang#2646 - rust-lang#2718 - rust-lang#2721 - rust-lang#2725

update Miri Noteworthy PRs: - rust-lang/miri#2357 - rust-lang/miri#2646 - rust-lang/miri#2718 - rust-lang/miri#2721 - rust-lang/miri#2725

saethlin mentioned this pull request Nov 4, 2022

Track local frames incrementally during execution #2647

Merged

rustbot added the S-waiting-on-author Status: Waiting for the PR author to address review comments label Nov 23, 2022

saethlin force-pushed the data-race-spans branch from 83b0f42 to 5458530 Compare December 16, 2022 16:22

saethlin marked this pull request as ready for review December 16, 2022 16:38

Include a Span in VClock

b06737e

saethlin force-pushed the data-race-spans branch from 5458530 to b06737e Compare December 16, 2022 16:39

rustbot added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Dec 16, 2022

oli-obk requested changes Dec 20, 2022

View reviewed changes

saethlin added 2 commits December 20, 2022 22:48

Fix span management

a799f02

Re-enable the VClock ordering tests

cca5ae9

oli-obk reviewed Dec 21, 2022

View reviewed changes

oli-obk approved these changes Dec 21, 2022

View reviewed changes

RalfJung reviewed Dec 21, 2022

View reviewed changes

Clean up implementation, deduplicate in errors

e589f0f

saethlin and others added 3 commits December 21, 2022 23:21

Fix phrasing

ba1fa88

Add a (1) and (2) to the data race errors

dad1669

attempt to clarify what the backtrace belongs to when there could be …

def32e1

…ambiguity

RalfJung reviewed Dec 23, 2022

View reviewed changes

Mention and number the components of a race in the order the interpre…

60a100a

…ter sees them

bors merged commit 4ec960f into rust-lang:master Dec 24, 2022

RalfJung mentioned this pull request Dec 24, 2022

update Miri rust-lang/rust#106121

Merged

bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 25, 2022

Auto merge of rust-lang#106121 - RalfJung:miri, r=RalfJung

298d763

update Miri Noteworthy PRs: - rust-lang/miri#2357 - rust-lang/miri#2646 - rust-lang/miri#2718 - rust-lang/miri#2721 - rust-lang/miri#2725

saethlin removed the S-waiting-on-review Status: Waiting for a review to complete label Dec 28, 2022

RalfJung pushed a commit to RalfJung/miri that referenced this pull request Dec 28, 2022

Auto merge of #106121 - RalfJung:miri, r=RalfJung

6f83431

update Miri Noteworthy PRs: - rust-lang#2357 - rust-lang#2646 - rust-lang#2718 - rust-lang#2721 - rust-lang#2725

saethlin deleted the data-race-spans branch January 15, 2023 22:04

spikespaz pushed a commit to spikespaz/dotwalk-rs that referenced this pull request Aug 29, 2024

Auto merge of #106121 - RalfJung:miri, r=RalfJung

9de478e

update Miri Noteworthy PRs: - rust-lang/miri#2357 - rust-lang/miri#2646 - rust-lang/miri#2718 - rust-lang/miri#2721 - rust-lang/miri#2725

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Data race spans #2646

Data race spans #2646

saethlin commented Nov 4, 2022 •

edited

Loading

RalfJung commented Nov 4, 2022 •

edited

Loading

bors commented Nov 13, 2022

RalfJung commented Nov 23, 2022

saethlin commented Dec 16, 2022

oli-obk Dec 20, 2022

saethlin Dec 21, 2022

oli-obk Dec 21, 2022

oli-obk Dec 21, 2022

RalfJung Dec 23, 2022

oli-obk left a comment

RalfJung Dec 21, 2022

RalfJung Dec 21, 2022

saethlin Dec 21, 2022

RalfJung Dec 21, 2022

saethlin Dec 22, 2022

RalfJung Dec 22, 2022

saethlin Dec 22, 2022 •

edited

Loading

RalfJung Dec 23, 2022

saethlin Dec 23, 2022 •

edited

Loading

RalfJung Dec 24, 2022

RalfJung commented Dec 21, 2022

saethlin commented Dec 22, 2022

RalfJung Dec 23, 2022

saethlin Dec 23, 2022

RalfJung commented Dec 24, 2022

bors commented Dec 24, 2022

bors commented Dec 24, 2022

bors commented Dec 24, 2022

Data race spans #2646

Data race spans #2646

Conversation

saethlin commented Nov 4, 2022 • edited Loading

RalfJung commented Nov 4, 2022 • edited Loading

bors commented Nov 13, 2022

RalfJung commented Nov 23, 2022

saethlin commented Dec 16, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oli-obk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

saethlin Dec 22, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

saethlin Dec 23, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung commented Dec 21, 2022

saethlin commented Dec 22, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung commented Dec 24, 2022

bors commented Dec 24, 2022

bors commented Dec 24, 2022

bors commented Dec 24, 2022

saethlin commented Nov 4, 2022 •

edited

Loading

RalfJung commented Nov 4, 2022 •

edited

Loading

saethlin Dec 22, 2022 •

edited

Loading

saethlin Dec 23, 2022 •

edited

Loading