{"id":27854,"date":"2021-04-07T23:31:51","date_gmt":"2021-04-07T23:31:51","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=27854"},"modified":"2021-04-07T23:31:51","modified_gmt":"2021-04-07T23:31:51","slug":"finding-bugs-with-addresssanitizer-msvc-compiler","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/finding-bugs-with-addresssanitizer-msvc-compiler\/","title":{"rendered":"Finding Bugs with AddressSanitizer: MSVC Compiler"},"content":{"rendered":"

Special thanks to Aaron Gorenstein for authoring this blog post. <\/em><\/p>\n

The AddressSanitizer (ASan) is generally available<\/a> for MSVC since the recently-released Visual Studio 2019 version 16.9. We\u2019ve already shown<\/a> how easy it can be to find bugs in even production-ready code like EASTL. Here I\u2019ll share an example of how it found a real bug in the MSVC compiler itself.<\/p>\n

The idea was straightforward: ASan finds bugs, and we\u2019re always interested in finding bugs in the compiler. Just like you can turn ASan on in your projects and run your tests, we\u2019ve been turning on ASan on our project (the compiler) and running it on our tests. Sure enough, this found bugs.<\/p>\n

 <\/p>\n

Building our Binary with ASan<\/h3>\n

It was easy to turn on ASan in our build system. We\u2019ve documented ways to turn ASan on in common<\/a> build<\/a> scenarios. In our case, I added \/fsanitize=address<\/code> to the build\u2019s cl.exe command line, and our old, ever-evolving build system needed the extra manual step of specifying where our extension<\/a> library lived.<\/p>\n

That was all it took! I now was able to build my binary, c2.dll, \u201cjust like normal\u201d, but now it had lots of excellent ASan instrumentation imbued to help find bugs. I was ready to run our inner-ring test suite and see if anything cropped up.<\/p>\n

 <\/p>\n

Finding the Bug<\/h3>\n

Our inner-test loop is about 4,000 separate C++ files, containing a mix of real-world-code, synthetic tests, benchmarks, and regression tests. We have a home-made test-runner that is only accessible from the command-line. Running it, we almost passed, but hit exactly 1 failure. I looked in our log file and see the characteristic trace:<\/p>\n

\"Image<\/a><\/p>\n

A couple things I would like to highlight:<\/p>\n

    \n
  1. The error reported is \u201cstack-buffer-underflow\u201d: this is a stack <\/em> ASan is able to find both stack and heap issues.<\/li>\n
  2. Note the line \u201cstack of thread T3\u201d. As that suggests, there is also a T1 and T2 (and more): c2.dll executes many threads in parallel. ASan can handle multiple threads like that no problem!<\/li>\n<\/ol>\n

    Most importantly: ASan never has false positives<\/strong>. This trace I found is definitely a bug, so I already know I found something to fix.<\/p>\n

    Fortunately, the triggering input is a single file. I can easily repeat the command that repro\u2019s the bug manually. To be clear, at this point this was all I needed to do to hit the issue:<\/p>\n

    \"Image<\/a><\/p>\n

    I\u2019ve truncated the output, but the terminal contained the full ASan command-line diagnostics. I could use that information (starting with the stack-trace you can see above) to investigate the issue. However, I like examining these in the full IDE and debugging experience. With this command line, I can reproduce the ASan issue but attach it to the debugger:<\/p>\n

    \"Image<\/a><\/p>\n

    Starting the debugger-attached version of my binary, I see:<\/p>\n

    \"Image<\/a><\/p>\n

    The IDE is able to provide a wealth\u2014interactively<\/em>\u2014of information about what\u2019s going on the moment<\/em> a memory violation is detected. You can see the ASan issue is reported as an exception, bringing me right to the correct line number, along with my familiar debugger call-stack and everything else. The output window is still available for those accustomed to it.<\/p>\n

    Any guesses of where the bug may be lurking?<\/p>\n

    Hint: \u201csz<\/code>\u201d likely stands for \u201csize\u201d. Observe recall how ASan reports \u201cstack buffer underflow<\/em>\u201d.<\/p>\n

     <\/p>\n

    Fixing the Bug<\/h3>\n

    Examining the value of sz<\/code> made it clear enough: MscIsFloatOrVectorConstant<\/code> returns the size of the constant if it is found<\/em>, and 0 otherwise. In this buggy case, it returns 0, and we underflow the array field in the function-local struct vval<\/code>. The fix is equally straightforward: following idioms in the rest of the file, we simply add a check for that before line 16828. This fix has been integrated and will be included in version 16.10.<\/p>\n

    This particular bug is very unlikely to strike \u201cin the wild\u201d: the stack would need to have garbage values in just-the-right way (to pass the condition on line 16831). However, in theory this bug\u2014and more generally, bugs just like it\u2014could lead to an improper optimization in your code. That is among the worst sort of bug a compiler can have: silent-bad-codegen. I\u2019m very pleased to have squashed this one. I\u2019m also very glad to have been able to share just how easy ASan can make bugfixing with you.<\/p>\n

     <\/p>\n

    Conclusion<\/h3>\n

    We don\u2019t typically write blog posts about fixing a bug in the compiler, but of course the real story is just how easily and effectively ASan helps find and fix bugs:<\/p>\n