An extremely simple program triggers an 'unhandled instruction' error when compiled with sanitizers

Question

I have this trivial C code (it could be C++)

$ cat .\main.c
#include <stdio.h>

int main() {
    printf("Hello");
    return 0;
}

When I compile it with address sanitizer.

clang -fsanitize=address main.c

And run, I get this error.

.\a.exe
==11224==interception_win: unhandled instruction at 0x7ff7d86bffd3: 4c 8d 15 26 00 f5 ff 49
AddressSanitizer: CHECK failed: sanitizer_common_interceptors_memintrinsics.inc:239 "((__interception::real_memcpy)) != (0)" (0x0, 0x0) (tid=8888)
    <empty stack>

Without address sanitizer, the program prints the message.

Environment:

Windows 11 & LLVM installed throughout choco

$ clang --version
clang version 17.0.5
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

I am doing something wrong? This should work fine, right?

Related: Crash at startup with address sanitizer and no relavant stack trace

Answer 1

I can confirm that we reproduce this problem.

Location of files: %ProgramFiles%\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC

Problem is in VS package: 14.38.33130 or maybe in newer or small older. Microsoft done a lot of changes in 14.38.33130 and we receive the same problem <empty stack>.

Temporary solution:

1. Go to %ProgramFiles%\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\
2. delete the package "14.38.33130" or other
3. copy there package "14.36.32532"
4. Rename directory name from "14.36.32532" to "14.38.33130"(or other which you had before)

In my opinion external LLVM and CMake is not compatible with new Visual Studio package.

Please note Microsoft change it just 1-3 weeks ago so a lot of person have older package and can not reproduce the problem, until upgrade the module.

Answer 2

I am doing something wrong?

There is nothing wrong with your C program.

This should work fine, right?

There is no good reason for Address Sanitizer to be emitting the diagnostic you present for the program listed in the question.

---

It is conceivable that the diagnostic is related to something you have done in setting up and configuring the machine or installing Clang, but I don't know any specific thing that would definitely cause the behavior you describe. My best guesses as to the nature of the issue are that either

1. It arises from the Clang build you installed having been built against a different version of the MS C-language runtime libraries than the ones that are actually on the system; OR

2. The Clang build you have installed is just buggy.