clang-cl address sanitizer doesn't work in x64

[Quuxplusone]

Bugzilla Link	PR37349
Status	NEW
Importance	P normal
Reported by	Denis (denisavvakumov@gmail.com)
Reported on	2018-05-07 04:00:16 -0700
Last modified on	2019-02-24 14:39:24 -0800
Version	6.0
Hardware	PC Windows NT
CC	filcab@gmail.com, kcc@google.com, llvm-bugs@lists.llvm.org, rnk@google.com, vitalybuka@google.com
Fixed by commit(s)
Attachments	image.png (10988 bytes, image/png)
Blocks
Blocked by
See also

Created attachment 20267
error in compiled executable

clang version: 7.0.0-r330570
additional command line options:
-v -fsanitize=address -fsanitize=undefined

linker options:
/OUT:"E:\projects\ConsoleApplication1\x64\Release\ConsoleApplication1.exe"
/MANIFEST /LTCG:incremental /NXCOMPAT
/PDB:"E:\projects\ConsoleApplication1\x64\Release\ConsoleApplication1.pdb"
/DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib"
"comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib"
"uuid.lib" "odbc32.lib" "odbccp32.lib" "clang_rt.asan-x86_64.lib"
"clang_rt.ubsan_standalone-x86_64.lib" /DEBUG /MACHINE:X64 /OPT:REF
/INCREMENTAL:NO
/PGD:"E:\projects\ConsoleApplication1\x64\Release\ConsoleApplication1.pgd"
/SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"x64\Release\ConsoleApplication1.exe.intermediate.manifest"
/OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1

Code used for test:
int main()
{
    HANDLE hLogFile = CreateFile(L"log.txt", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    char test[3]={0x90,0x90,0x90};
    int i = INT_MAX;
    test[2] = i++;
    test[4] = '1';
    system("pause");
    return 0;
}

[Quuxplusone]

Attached image.png (10988 bytes, image/png): error in compiled executable

[Quuxplusone]

Copy-pasting the error message from the cmd prompt would be more helpful than a
screenshot. In any case, this CHECK inside INIT_MEMCPY is failing:

#define INIT_MEMCPY                                  \
  do {                                               \
    if (PLATFORM_HAS_DIFFERENT_MEMCPY_AND_MEMMOVE) { \
      COMMON_INTERCEPT_FUNCTION(memcpy);             \
    } else {                                         \
      ASSIGN_REAL(memcpy, memmove);                  \
    }                                                \
    CHECK(REAL(memcpy));                             \
  } while (false)

After this code block, somehow __interception::real_memcpy is still null. On
win64, we go down the ASSIGN_REAL code path, which probably expands to
`__interception::real_memcpy = __interception::real_memmove`. This means we
somehow failed to find or intercept memmove. You can re-run with
ASAN_OPTIONS=verbosity=2 to find out more about that.

I have no time to investigate this right now, but chances are that this is some
environmental bug specific to your exact version of Windows.

[Quuxplusone]

I did a little research the problem is fixed by enabling the option "Use MFC in
a Static Library". Can you please find out why?

About my environment:
Windows 10 x64, build 17134 (April update)
Visual Studio 2017 (15.7.1)

[Quuxplusone]

I don't know why MFC would affect it, but if you are linking the *CRT*
statically, that makes it much easier to intercept memmove, which would fix the
issue that you're seeing.

I don't have time to investigate, unfortunately.