Address Sanitizer-like functionality on MSVC

Frank Meerkötter picture Frank Meerkötter · Dec 8, 2017 · Viewed 10.8k times · Source

Coming from Linux/gcc/clang I find myself working more and more on Windows/Visual Studio.

What I am really missing there is the address sanitizer (bounds checking, leaks, use after free,...). I've done some research and also tried a few things but haven't found a replacement that is complete (feature-wise) as well as reliable. I've tried Dr. Memory for example but learned it doesn't work for Qt-based programs (at least not on Windows 10).

So how do I get address sanitizer-like functionality on Windows/MSVC?

Answer

FourtyTwo picture FourtyTwo · Feb 2, 2018

At least ASan and Ubsan from clang are supposed to work on Windows, with some limitations. These can be used with msvc toolchains using clang-cl as a drop-in replacement for cl.exe - google seems to be working on this, mozilla too.

Issues that I am aware of (and that keeped me from using it myself until now):

  • linking with the required libraries is not automatic. There are two versions of them, depending on how the CRT is linked in your application ( /MT means static CRT, /MD means dynamic CRT, the latter is typically used in Qt). To find the required linker parameters, open Visual Studio command prompt, add clang bin folder to the path, and compile a simple main.cpp (empty main function) with verbose options with clang-cl like this: clang-cl -v /MD -fsanitize=address main.cpp The required link.exe command is in the end of verbose output, extract the required libs for linking from there.

  • only release builds are supported on Windows

  • no support for exceptions on Windows ( see this issue)

  • there doesn't seem to be much further work on the Windows port, the wiki e.g. is terribly outdated (last change in 2015), so I doubt that many people are using this productively. So getting help from other users online might be quite hard ...

Talking about other alternatives on Windows, there are:

Sanitizers and Valgrind on Linux IMO are much more advanced and/or have much better performance than these tools, so keeping an application building on Linux seems the best idea, at least when working with a cross-platform toolkit like Qt (as you are mentioning).