[HW4] (Thread Sanitizer has been running for 10 minutes) about cs431 HOT 6 CLOSED

1. It can be racy if you are mixing it with non atomic accesses. The error message also suggests that (note the addr is the same)
2. TSAN does typically take longer.... not sure why the loop happens tho.
3. Do you have llvm-symbolizer enabled? That should tell where the racy accesses are happening, and you should look into those.

from cs431.

Regarding question 2, taking too much time in testing can be a strong signal that your code can result in deadlock. Even if your code passes other tests with cargo or cargo_asan, unlucky scheduling with cargo_tsan may result in deadlock. Note that our model solution takes at most 1 min for testing with cargo_tsan, so testing should not take that much long as in your case (>30min).

from cs431.

1. Yes, I know that they have the same address, and it says Atomic write, and when I see the backtrace, indeed the first function in the backtrace was an atomic operation. I am confused about this.
2. It is version 14. And I executed the following command shown in manual: sudo ln -s /usr/bin/llvm-symbolizer-14 /usr/bin/llvm-symbolizer But I don't see helpful messages though

from cs431.

1. It can be racy if you are mixing it with non atomic accesses. The error message also suggests that (note the addr is the same)
2. TSAN does typically take longer.... not sure why the loop happens tho.
3. Do you have llvm-symbolizer enabled? That should tell where the racy accesses are happening, and you should look into those.

this is one of the summaries generated by sanitiser:

SUMMARY: ThreadSanitizer: data race /home/ubuntu/.rustup/toolchains/nightly-2024-03-13-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/sync/atomic.rs:3361:23 in core::sync::atomic::atomic_sub::h5c8653b27dead1c1

Is this how it is supposed to print after llvm-symbolizer is enabled?

from cs431.

Yes that looks correct. In terms of the data race, what I meant is that from the summary you posted:

WARNING: ThreadSanitizer: data race (pid=1183058)
Atomic write of size 8 at 0x720c00005a58 by thread T35:
Previous write of size 8 at 0x720c00005a58 by thread T32:

The two writes by T32 and T35 are racing, so it's probably the case that the write by T32 is non-atomic.

from cs431.

Thanks! This helped to debug it!

from cs431.