Vulkan API Version: 1.2.194
Vulkan Driver Version: 511.92.0
==22580==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x12a87a397f20 in thread T0
==22580==WARNING: Failed to use and restart external symbolizer! #0 0x7ff922dad301 in _asan_wrap_GlobalSize+0x4a71d (C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\clang_rt.asan_dynamic-x86_64.dll+0x18004d301) #1 0x7ff9b00af4e4 in RtlGetFullPathName_UstrEx+0x1c54 (C:\Windows\SYSTEM32\ntdll.dll+0x18001f4e4) #2 0x7ff9b00b0b30 in RtlTryEnterCriticalSection+0x350 (C:\Windows\SYSTEM32\ntdll.dll+0x180020b30) #3 0x7ff9b00bbed9 in RtlAllocateHeap+0x1539 (C:\Windows\SYSTEM32\ntdll.dll+0x18002bed9) #4 0x7ff9b00bb3c6 in RtlAllocateHeap+0xa26 (C:\Windows\SYSTEM32\ntdll.dll+0x18002b3c6) #5 0x7ff922dac47c in _asan_wrap_GlobalSize+0x49898 (C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\clang_rt.asan_dynamic-x86_64.dll+0x18004c47c) #6 0x7ff9add4acb2 in GlobalAlloc+0x82 (C:\Windows\System32\KERNELBASE.dll+0x18005acb2) #7 0x7ff9285d11c3 in DrvValidateVersion+0xaaa3 (C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_015fa42d67826549\nvoglv64.dll+0x180da11c3) #8 0x7ff9289eae73 in vkGetInstanceProcAddr+0x4d653 (C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_015fa42d67826549\nvoglv64.dll+0x1811bae73) #9 0x7ff75deeeb97 in DoRenderer::init C:\Users\phild\projects\gnometower\gnomes\do_renderer.cpp:704 #10 0x7ff75df37969 in DoRendererVParticle::init C:\Users\phild\projects\gnometower\gnomes\do_renderer_vparticle.cpp:345 #11 0x7ff75de6ece8 in GTApplication::run C:\Users\phild\projects\gnometower\gnomes\application.cpp:242 #12 0x7ff75de6f43b in main C:\Users\phild\projects\gnometower\gnomes\application.cpp:1012 #13 0x7ff75e091327 in __scrt_common_main_seh d:\a01_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 #14 0x7ff9af737033 in BaseThreadInitThunk+0x13 (C:\Windows\System32\KERNEL32.DLL+0x180017033) #15 0x7ff9b00e2650 in RtlUserThreadStart+0x20 (C:\Windows\SYSTEM32\ntdll.dll+0x180052650)
Address 0x12a87a397f20 is a wild pointer.
SUMMARY: AddressSanitizer: bad-free (C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\clang_rt.asan_dynamic-x86_64.dll+0x18004d301) in _asan_wrap_GlobalSize+0x4a71d
Using the following setup (all updated to latest publicly available):
GeForce Game Ready Driver 511.23
Vulkan SDK 1.2.198.1
Win 10 19043.1503
Microsoft Visual Studio 16.11.9
Visual C++ 2019 - 00435-60000-00000-AA228
Is there anything I can do to get a response on this? Or at least verify it has the attention of the driver devs? I can’t use asan in my project until this gets fixed!
Happy to help and/or provide more information if needed!
Thank you for so diligently reporting issue on the Vulkan drivers. I had a look at your past posts and I am sorry that you didn’t get the help you were looking for.
Could you maybe add a bit more context to help us understand what the actual problem is? It is not clear to me how the Asan run relates to the Vulkan driver. How would do you deduct from the above stack trace that the tool recognized the bad address handling within the NVIDIA driver?
It’s a “free unmalloced address” when I call vkGetInstanceProcAddr (see stack frame #8 in nvoglv64.dll). I guess it could be somewhere in ntdll.dll, but my assumption is it’s as shallow in the stack as is plausible, and it isn’t in my code (which just calls vkGetInstanceProcAddr and certainly doesn’t free anything).
This asan error comes up when I compile and run my project with asan, and (as I show above) points to an error through the nvoglv64.dll stack frame, and then the program terminates, so I am unable to use asan with my project until this is fixed.
Happy to provide any other information you’d like, but I’m not sure how to be more clear. Is there some assumption I’m making that is incorrect? Is nvoglv64 not indicative of the nvidia driver?
Thanks for the quick update.
To clarify, I will also bring this to the attention of the Vulkan driver team to get more input and to make sure we don’t miss any potential bug. Meanwhile let me try to help as much as I can.
nvoglv64.dll is the NVIDIA driver, correct. The reason I was asking was that there is an arbitrary memory address without exact signature of the function that tried to access that specific memory address. The stack trace ends in a kernel module, so it could happen anywhere in between.
Asan instruments DLLs that are not compiled with an Asan compiler flag (like nvogl or any of the Windows libraries) by checking for signatures of for example malloc, free, new or delete during runtime. For that to work together with your instrumented sources, the Asan runtime needs to be loaded before any part of the executable that was compiled with the -fsanitize=address flag. So please make sure you preload the Asan runtime. You should find information on how to do that in the MSVC Asan documentation.
Finally, the best way to help us investigate further is if you could provide a minimal reproducible example, meaning a small application that shows exactly the same behavior. That way we can hopefully reproduce it easily and find the potential bad free in our driver.
The reason why I ask all this is simply that we of course use all kinds of static and runtime analysis tools on our drivers. So I hope you can understand that I would be surprised if we overlooked a bad free in as essential a function as vkGetInstanceProcAddr.
Also to unblock you in the short term, if you would be able to use Clang for compilation, you can whitelist external libraries, see the CLang documentation on it.
At the time of the bug, I had simply enabled address sanitizer in visual studio’s project properties. It had worked for me in the past without any further modification.
I’m unfortunately not sure what you mean by “ensuring I preload the asan runtime”, and reading through the MSVC asan documentation I saw nothing regarding that.
However, I’ve since upgraded to VS 2022, and can no longer reproduce the bug (asan now runs with no error). I’m not sure what the issue was before, but I think it is reasonable to assume it was user error- I would love to better understand what steps I might have been missing, but for now my issue is resolved.
Thanks again for your responses- and I hope I didn’t waste too much of anyone’s time!
You most definitely did not waste anyone’s time, no worries.
My guess why it is working now would really be a mismatch in libraries needed by the compiler, driver and Asan. If you read through the documentation you will see, that Asan has a lot of both soft and hard requirements in terms of environment. That means that I doubt it was a user error but rather lack of proper setup help and documentation.
The preload comment comes from the final Note in one of the official announcement blog posts from Microsoft as well as some other comments I found. In the CLang/gcc world you have the LD_PRELOAD directive that allows you to specify the Asan runtime to be loaded before any other libraries. I am not certain if MSVC has something similar when building from the IDE, but at least you need to disable incremental linking, which is also mentioned in the Docs.
In any case, I am happy that you could resolve your issue! Best of success with your project!
Hi. I have the same problem after MSVC update to 14.29.30133. Looks like problem in address sanitizer library.
Builds with MSVC 14.28.29910 works fine.