sanitizers

er MSan: MemSan: MemorySanitizer Google/sanitizers is archived because it was merged into LLVM sanitizers. https://github.com/google/sanitizers/ : > The Sanitizers project, which includes AddressSanitizer, MemorySanitizer, ThreadSanitizer, LeakSanitizer, and more, is now archived. LLVM Clang docs > AddressSanitizer: https://clang.llvm.org/docs/AddressSanitizer.html There's a google/sanitizers wiki page from 2019 about Stack Instrumentation with ARM MTE Memory Tagging Extensions: https://github.com/google/sanitizers/wiki/Stack-instrumentat... /? MemTagSanitizer https://www.google.com/search?q=MemTagSanitizer "Color My World: Deterministic Tagging for Memory Safety" (2022) https://arxiv.org/abs/2204.03781 : > 7.3 Pointer-safe tagging: Recall that safe allocations could still allow inter-object cor- ruption unless it is also pointer-safe (Sections 5.3 and 6.3). To distinguish such safe, but pointer-unsafe allocations, we tag them using the 0b10xx. Consequently, we can at run-time distinguish pointers loaded from pointer-safe allocations, and apply tag forgery prevention to all other loaded pointers. LLVM Clang docs > MemSanitizer: https://llvm.org/docs/MemTagSanitizer.html : > Introduction: Note: this page describes a tool under development. Part of this functionality is planned but not implemented. Hardware capable of running MemTagSanitizer does not exist as of Oct 2019. > MemTagSanitizer is a fast memory error detector and a code hardening tool based on the Armv8.5-A Memory Tagging Extension. It detects a similar class of errors as AddressSanitizer or HardwareAssistedAddressSanitizer, but with much lower overhead. > MemTagSanitizer overhead is expected to be in low single digits, both CPU and memory. There are plans for a debug mode with slightly higher memory overhead and better diagnostics. The primary use case of MemTagSanitizer is code hardening in production binaries, where it is expected to be a strong mitigation for both stack and heap-based memory bugs. -fsanitize=memtag Code sanitizer: https://en.wikipedia.org/wiki/Code_sanitizer -fsanitize

m there is no happens-before relationship between the thread you spawn and the main thread, so there is a data race by the TSAN definition, even though the read and the write are atomic, and even if a given execution of that code by TSAN doesn't yield an error. It's not about timing, at least not exactly -- it's about the guarantees of the scheduler and its execution of threads, which is non-deterministic without explicit synchronization in the application (or something along those lines)..! [1] https://github.com/google/sanitizers/wiki/ThreadSanitizerAbo...

d because the history buffer wasn't large enough, then obviously it's not conclusive. But if it wasn't flagged because TSAN noticed it and deliberately exempted it, then obviously it doesn't consider it a data race. [1] https://github.com/google/sanitizers/wiki/ThreadSanitizerFla...

a single word anywhere -- not in the docs, not in example code, and (I think) not even from anyone here other than you -- suggesting that TSAN considers memory_order_relaxed writes to constitute a data race. It certainly does not flag them in the most trivial test I could think of, which I had already linked here [3]. If this is just my ignorance or misunderstanding, then instead of telling me to go do my own reading, please enlighten me and provide one link or example that demonstrates that TSAN considers atomic writes to the same memory to be a data race? I would be very glad to learn this, as I wasn't aware of this before, and am not seeing anything suggesting such. > Those comments have included pretty detailed information as to exactly how and when and why your definition isn't totally correct. I have linked to papers going back decades showing that "data race" has a general definition that don't entirely match up with what people have said. I myself have also explained in great detail how the general definition differs from the C++ one. I don't know what else to possibly provide here, but I'm done. [1] https://clang.llvm.org/docs/ThreadSanitizer.html [2] https://github.com/google/sanitizers/wiki/threadsanitizercpp... [3] https://godbolt.org/z/EjWWac1bG

[0] https://github.com/google/sanitizers

mentally better ways to test software) - you get less contributions or need to spend more on getting people onboarded. Note that even if "training" people is free in the sense that there is no paid training material, you still pay a cost in lower productivty for new people and the time spent training. Even once people are trained, you now have a process/institutional need to support the property based tests you wrote. That may mean paying for licenses for software, or maintenance of whatever infrastructure/integrations you write to get property based testing working in your developer workflow. And you also now need to rely on people using these tools correctly - the problem with formal verification is that it doesn't verify that you're actually solving the real problem correctly, just that your program operates as expected (ie it only verifies that your software is Working As Implemented, not Working as Intended). The more you rely on average joes to wield complex things like this well, the more headaches you introduce - if the bottom 10% of people you hire use it sloppily or wrongly, once you're past a few dozen regular contributors you're basically going to have constant issues. You see this all the time with even just regular unit and integration tests - less capable developers constantly introduce flakes or write tests so bad/basic that it'd be better for them to not even be writing tests at all. Even if after considering all that it still seems a worthy tradeoff, there's the question of whether property based testing solves the problem you think it does. As I mentioned, it can moreso verify software is Working as Implemented rather than Working as Intended. But there is the bigger problem of major software projects not conforming to the simpler use cases that sell people on using this tool. In my experience stateless functions almost never have bugs, and when they do, it's mostly a "requirements discovery" problem you wouldn't catch with any kind of verification tooling. Stateful verification becomes a problem in the kinds of real systems programming projects like the Linux Kernel or Qemu which stand to benefit most from verification. If you're verifying things at the level of a "higher level" abstraction like a scheduler, you almost always have really high dimensionality/a lot of state, perhaps deceptively more than you think, because of composition. And you tend to also have a devloop that is already very slow - builds take a long time, and running tests of higher level components can be "expensive" because it may take 100ms-1s for something like a kernel to finish starting in a test environment. For a single test that's nothing, but multiplied across all tests makes testing painful enough already; adding 3x or 100x by doing property based testing with new tests, even if pruned before submitting, could be either hugely expensive or way too slow. And similarly, the increased resource requirements to maintain state machines can be very expensive. TSAN does essentially parallel property-based testing and introduces 128-512 bytes of overhead for every 8 bytes of memory under test: https://github.com/google/sanitizers/wiki/ThreadSanitizerAlg.... Is it cool and underrated? Definitely. But it's not a silver bullet and honestly just isn't worth it for most software. Even when it is worth it, it has its drawbacks.