cpp-best-practices / gui_starter_template

A template CMake project to get you started with C++ and tooling

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Address Sanitizer broken on Windows

LtdSauce opened this issue · comments

Hi,

i noticed that the CI-Builds from this template fail for Windows and MacOS when i enable the AddressSanitizer:

CMakeLists.txt
@@ -38,7 +38,7 @@ project_options(
      # ENABLE_USER_LINKER
      # ENABLE_BUILD_WITH_TIME_TRACE
      # ENABLE_UNITY
-     # ENABLE_SANITIZER_ADDRESS
+    ENABLE_SANITIZER_ADDRESS
      # ENABLE_SANITIZER_LEAK
      # ENABLE_SANITIZER_UNDEFINED_BEHAVIOR
      # ENABLE_SANITIZER_THREAD

I also noticed this behavior on my local machine on Visual Studio 2019 16.11.9 when enabling AddressSanitizer. Because this happens on CI and my machine i assume something is wrong with how the sanitizer is enabled through project_options? (I decided to open the issue here though as i would start searching here when running into this problem)

I commited the above on my fork of the template: https://github.com/LtdSauce/cpp_starter_project
See actions there for the failed builds.
TL;DR: On Windows all executables fail with the following return Code 0xc0000135. That seems to happen when a dll cannot be loaded.
On MacOS i have no clue what goes wrong as i never have worked with MacOS before.

As i am not native to Windows i have no clue how to tackle this issue on my own...
Has anyone run into this before and knows how to fix it?

For Windows, this is because vcvarsall is not running in the CI. #183 Fixes this.

To use address sanitizers on Windows, you should run vcvarsall x64 in the terminal that you run the code (or use Visual Studio Command Prompt). The error code is because of the failure to link the sanitizer dll files.

During the build, project_options tries to run vcvarsall automatically here:
https://github.com/cpp-best-practices/project_options/blob/03a9473da98e02cc6924271f465826141b030f39/src/VCEnvironment.cmake#L28

If it fails to do so, it will throw an error here:
https://github.com/cpp-best-practices/project_options/blob/03a9473da98e02cc6924271f465826141b030f39/src/Sanitizers.cmake#L75

But it cannot link the DLL files during the build. You should do this yourself. I suppose we can detect if runtime sanitizer DLLs are required and issue a warning to the user.

The BUILD_TYPE issue kept me away from this today.

I'll try to apply your suggestion in the next days.

For Windows, this is because vcvarsall is not running in the CI. #183 Fixes this.

@lefticus will #181 also fix this for local builds?

@LtdSauce yes it fixes it for local builds (use inside of VS that is), but not for CI. I'm working on getting this merged: aminya/project_options#46 so we can get the fixes on #181 merged.

I think this has been fixed in all of the recent work of the last 2 weeks. @LtdSauce any chance you can verify your issues are resolved?

I'll try to verify this on the weekend.

Thanks! I have verified things on my side, but I know this IDE experience is not something we can run automated tests against

@lefticus Hmm i'm not sure if i still do something wrong. I did a fresh clone of this repository and tried both of the following with the defaults:

  • configure and build it with Developer PowerShell for VS 2022 on the commandline (used cmake-gui)
  • Opened it with Clion 2021.3.3 and build it with Visual Studio Generator and Ninja Generator

Both methods were not able to locate the DLL for the Asan runtime. Is this still expected? (i installed Visual Studio through the Buildtools installer and asan runtime is definitely installed)

@aminya wrote:

But it cannot link the DLL files during the build. You should do this yourself. I suppose we can detect if runtime sanitizer DLLs are required and issue a warning to the user.

Do i still have to do that manually or have you expected this to work by now?
I do not have the Visual Studio IDE installed right now, so i cannot verify if it works that way.

Thanks for the effort so far!

PS: I'm considering switching to docker desktop development to avoid all the windows stuff i'm not familiar with 😅

@LtdSauce I thought you were trying to trying to run within Visual Studio, which is the process that should be fixed.

I would also expect the version from a developer shell to work, I can test that.

CLion + visual studio is not anything I've ever tried before.

I'll take a look at these other configurations.

Yes i thought Visual Studio and the Developer PowerShell would be somehow "the same"... At least in terms of compatibility.

Sorry for the confusion!

Interesting...

Developer PowerShell for VS2022 does not load vcvarsall.bat automatically. While Native Tools Command Prompt For VS2022 does load vcvarsall.bat (and our project works from there)

After doing some searching around I'm at a loss as to the intended use of the Developer PowerShell. It has tools set up, but not any of the necessary variables for finding things.

I'll give the command prompt a try as soon as i can.

@LtdSauce You need to run vcvarsall.bat x64 in the same shell that you build and run the code.

Alternatively, if you search for "Developer Command Prompt", there will be a shortcut.

image

Open that prompt, then run:

  • open PowerShell
pwsh 
# or powershell
  • open clion
& "C:/Program Files (x86)/JetBrains/CLion 2021.3.3/bin/clion64.exe" path_to_project

@LtdSauce You need to run vcvarsall.bat x64 in the same shell that you build and run the code.

@aminya that one works in command prompt but not in Powershell.
I falsly thought it is already done by program_options because i had not seen the warning mentioned in your first reply.

PS: Thanks for the solution to get Clion working! I'll try it tomorrow.

@lefticus i can now verify the following things:

  • Asan support works out-of-the-box in VisualStudio 2022 Community Edition (Tests compiled and executed cleanly)
  • The setup solution from @aminya (running vcvarsall.bat in Developer Command Prompt and then launch IDE from their worked on CLion and VS Code

My issues are resolved or worked around (CLion).

@aminya One note about project_options/src/Sanitizers.cmake#L75: I think the check is broken. It currently compares the string "index_of_vs_install_dir" and "-1" which is never equal. I think it should be if("${index_of_vs_install_dir}" STREQUAL "-1") to realy trigger that error. Though that error even triggers when i opened clion from the vcvarsall loaded CLion and working asan support. Should i open another issue in project_options or is this related enough to stay here?

PS: I expanded both of the variables that are checked. $PATH contains many paths that start with $VSINSTALLDIR but none of them match directly. I think $PATH and $VSINSTALLDIR are mixed up, as the first argument should be the string to search in and the second is the substring to search for in the string. See Cmake String docs
PPS: I opened aminya/project_options#70 to address that error. (Please excuse if this is not related to this issue)