Introduction
It has been an exciting few months for the Address Sanitizer (ASan) since our last update. In addition to our continuous focus on quality and correctness, our internal “dogfooding” (i.e. internal adoption) effort has reached several important milestones.
In this update, I want to go over some of the quality improvements since Visual Studio 2022 version 17.13, and to give a peek into how ASan is now protecting our C++ toolset against memory safety errors during development.
Some improvements in Visual Studio 2022 version 17.14
- We increased the number of ASan flags that can be set through
__asan_default_options, the alternative to the environment variableASAN_OPTIONS. This was an adoption blocker for apps that, for security reasons, can’t access the environment during execution. - For Xbox developers, we now have automated testing ensuring that ASan’s dependencies are compatible with the Xbox OS. This is important since we now integrate changes from upstream LLVM on a weekly basis, meaning that we need to actively guard against Xbox-incompatible changes.
- We fixed a regression that corrupted the callstack displayed during error reporting in x64.
- Improved stability by removing the lazy loading of
DbgHelpsymbolization helpers, minimizing loader lock contention. - In the STL, we now allow ASan container annotations to be disabled on a per-allocator basis. This allows users to control container poisoning, which is useful when custom allocators (e.g. arenas) are in use.
This release also contains several other improvements, many of which were contributed by the ASan open-source community in the LLVM repo. By contributing to LLVM upstream, you are also contributing to MSVC’s ASan. We thank the entire LLVM ASan community for their efforts, and plan to continue contributing our improvements upstream as well.
Protecting the C++ toolchain
To protect the toolchain against memory safety errors, all PRs made against the MSVC toolset and libraries now need to pass ASan instrumentation tests. These are tests where the compiler itself is instrumented with ASan to catch memory safety violations while executing our compiler test suite.
To be clear, this is different from compiling test programs with ASan, i.e. having the compiler run /fsanitize=address on some .cpp file. Instead, the compiler itself is built with /fsanitize=address before executing its test matrix so that ASan may monitor allocations during compilation.
Through this process, we have learned a lot about how to adopt ASan in a large and historied codebase like MSVC and it’s helped us drive several improvements in both the toolset as well as in ASan itself, so we’re excited about the quality improvement cycle that dogfooding ASan within MSVC unlocks for us.
Let’s harden our C++ code together!
The ASan team is proud to help you secure your C++ applications, and we would love to hear from you. If you’re not using it already, download Visual Studio and give the Address Sanitizer a try. We can be reached out through the comments below and through our official support channels: Developer Community or through Visual Studio by clicking Help > Send Feedback > Report A Problem / Provide a suggestion in the product.
Until next time!
Still no LSan (ノಠ益ಠ)ノ彡┻━┻
Hi,
ASAN found some nasty problems in our code base! Thank you for providing this tool on msvc.
Our automated UI-Tests use ASAN Builds once in a week and suddenly we get crashdumps we cannot open.
We get “Element Not Found. (Exception from HRESULT: 0x80070490)” Messages when we try to open them.
What could be the reason for this?
Hmm, that doesn’t a ring bell. I did a quick search over our issue tracker and didn’t find a match for “Element Not Found.” and that particular “HRESULT”.
Please report the issue with as many details as possible on devcomm: https://developercommunity.visualstudio.com/cpp/report
As expect, this will be easiest for us to repro if you’re able to provide a minimal reproducer to share with us. That tends to be the biggest barrier towards a fast resolution, so if you have some cycles to help us minimize the scenario, that would be great. Thank you!
I’m sorry for the frustration. It’s definitely on our radar, we know it’s highly requested.
As always, upvoting on devcommunity helps move the needle in funding these things: https://developercommunity.visualstudio.com/t/support-leaksanitizer/826620
The number of traditional leaks I’ve had to investigate this year so far: 0. The number of runtime undefined behavior bugs, caught by fsanitize=undefined on other toolchains, that I’ve needed to look at: 3.
Traditional leaks are gone in code bases adopting modern standards. We want the undefined sanitizer instead:
https://developercommunity.visualstudio.com/t/Add-support-for-UBSAN-UndefinedBehavior/840750
https://developercommunity.visualstudio.com/t/Support-UBSanUndefinedBehaviorSanitizer/1393846