vkSetDebugUtilsObjectNameEXT() causes a crash when attempting to set a name for VkPhysicalDevice

I am attempting to set a name for a VkPhysicalDevice handle with vkSetDebugUtilsObjectNameEXT(). The crash seems to occur in nvoglv64.dll:

sample.exe!terminator_SetDebugUtilsObjectNameEXT(VkDevice_T * device, const VkDebugUtilsObjectNameInfoEXT * pNameInfo)
Exception thrown at 0x00000000579B727D (nvoglv64.dll) in sample.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

The exactly same call doesn’t crash with a VkDevice handle, or with a VkSurfaceKHR handle although it is not a child of VkDevice. I couldn’t find any info whether handles that are not children of VkDevice can be named with vkSetDebugUtilsObjectNameEXT().

My OS is Windows 10 Pro 1803 (build 17134.885), GPU is GeForce GTX 970, the driver version is 431.60 and the Vulkan version is 1.1. I have built the Vulkan loader myself using revision tag “v1.1.108”.

I am seeing a very similar crash, linux with a GeForce GTX TITAN X, driver version 430.50, Vulkan version 1.1. Debian trusty x86_64.

I am about 90% sure the issue is the nvidia driver 430.50, because I was previously running driver 430.26. I updated the driver and Dear ImGui, then the app began crashing.

I hit a crash when attempting to call vkSetDebugUtilsObjectNameEXT on a VkDevice handle. Here is the call stack:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3f95eab in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.430.50
(gdb) bt
#0  0x00007ffff3f95eab in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.430.50
#1  0x00007ffff3fa58e1 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.430.50
#2  0x00007ffff7f6b5dc in terminator_SetDebugUtilsObjectNameEXT (device=0x555555be0d50, pNameInfo=0x7fffffffd340)
    at ../../vendor/volcano/vendor/vulkan-loader/loader/generated/vk_loader_extensions.c:2462
#3  0x000055555562e52b in language::setObjectName (dev=..., handle=1, objectType=VK_OBJECT_TYPE_DEVICE, 
    name=0x7fffffffd610 "cpool.vk.dev") at ../../vendor/volcano/src/core/VkPtr.h:263
#4  0x0000555555574425 in language::Device::setName (name="cpool.vk.dev", this=0x555555b009c0)
    at ../../vendor/volcano/src/core/VkPtr.h:278
#5  example::Example08::buildPass (this=0x555555b11b60) at ../../08specialization/08specialization.cpp:252
#6  0x00005555555759dc in example::Example08::run (this=0x555555b11b60) at ../../08specialization/08specialization.cpp:429
#7  0x0000555555578309 in example::createApp (window=<optimized out>) at /usr/include/c++/8/bits/shared_ptr_base.h:1307
#8  0x0000555555578533 in example::crossPlatformMain (argc=<optimized out>, argv=<optimized out>)
    at ../../08specialization/08specialization.cpp:487
#9  0x0000555555578565
 in main (argc=<optimized out>, argv=<optimized out>)
    at ../../08specialization/08specialization.cpp:509

Steps to reproduce:

  1. git clone https://github.com/ndsol/VolcanoSamples

  2. cd VolcanoSamples

  3. ./build.cmd

(wait a while, it will clone and build the vulkan loader in out/Debug)

  1. Run:
gdb --args out/Debug/08specialization

Bump, anyone at NVidia able to take a look at this?

Cord, for the callstack you pasted above, this looks suspicious:
#3 0x000055555562e52b in language::setObjectName (dev=…, handle=1, objectType=VK_OBJECT_TYPE_DEVICE,
name=0x7fffffffd610 “cpool.vk.dev”) at …/…/vendor/volcano/src/core/VkPtr.h:263

Notice the “handle=1”, which is not a valid handle for the device. Perhaps that’s a bug in the 08specialization app, or perhaps it’s a handle from a layer which the loader or layer is not replacing with the real handle for the device before giving it to the driver.

Devenec, for your issue it might have been a driver bug. Can you try the latest 441.99 beta driver from https://developer.nvidia.com/vulkan-driver and see if it has been fixed.

Hi pdaniell,

doesn’t work with 441.99. I am still getting the same “Access violation reading location 0xFFFFFFFFFFFFFFFF.”

Devenec, how are you getting the function pointer for vkSetDebugUtilsObjectNameEXT? Since this is an instance extension it should be with vkGetInstanceProcAddr(). If vkGetDeviceProcAddr() is used, and are also using layers, it’s possible the VkPhysicalDevice handle isn’t being unwrapped correctly and the driver ends up trying to deference a layer handle.

Also note this loader bug, which may also be affecting you: https://github.com/KhronosGroup/Vulkan-Loader/issues/116

1 Like

I am using vkGetDeviceProcAddr(), probably because vkSetDebugUtilsObjectNameEXT() takes a VkDevice as a first parameter. Changing to vkGetInstanceProcAddr() solved the issue. Thank you!

Glad to hear it’s working. Yeah using vkGetInstanceProcAddr() it a bit counter-intuitive, but that’s currently the rule for instance extension functions, even ones with a VkDevice as their first parameter. The Vulkan spec might get updated in this regard and allow vkGetDeviceProcAddr() to be used for these functions. If that happens implementations will get updated to support it too.