vkSetDebugUtilsObjectNameEXT crashes with VkInstance and VkPhysicalDevice

[tlf30]

Version

3.3.1

Platform

Windows x64

JDK

Adoptium 17

Module

Vulkan

Bug description

vkSetDebugUtilsObjectNameEXT crashes when naming a VkInstance or VkPhysicalDevice. This appears to be cause by using the function pointer for vkSetDebugUtilsObjectNameEXT from the VkDevice instead of the VkInstance.
More info can be found here:
https://forums.developer.nvidia.com/t/vksetdebugutilsobjectnameext-causes-a-crash-when-attempting-to-set-a-name-for-vkphysicaldevice/79517/6

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.

EDIT: Also take note: KhronosGroup/Vulkan-Loader#116

Stacktrace or crash log output

https://gist.github.com/tlf30/ff2ed51abf4894add8960a11f4ee5057

Please let me know if you need anything else.
Thank you,
~Trevor

[Spasi]

Thank you @tlf30!

[tlf30]

Thank you for the fix @Spasi, I will test as soon as a snapshot is available.

[tlf30]

@Spasi I just tested with the 3.3.2 snapshot. Setting a name on aVkPhysicalDevice works now, but setting the name on a VkInstance does not, it throws a memory access violation. I am setting up a test with native code to check if it is a driver issue, as I believe the bindings are correct.

[tlf30]

@Spasi I have dove into this further. Currently the JVM just crashes with Process finished with exit code -1073740940 (0xC0000374) (IDEA is adding the extra text, just the exit code, no crash log was generated by the jvm).
Java Test Code:

try (MemoryStack stack = MemoryStack.stackPush()) {
    vkSetDebugUtilsObjectNameEXT(
            device.getDevice(),
            VkDebugUtilsObjectNameInfoEXT.calloc(stack)
                    .sType$Default()
                    .objectType(VK_OBJECT_TYPE_INSTANCE)
                    .pObjectName(stack.ASCII(name))
                    .objectHandle(instance.getNativeHandle())
    );
}

I put together a C++ test, and it worked as expects. This also eliminates a driver issue as I tested on the same machine.

 //Test setting instance debug name
VkDebugUtilsObjectNameInfoEXT info;
info.sType = VK_STRUCTURE_TYPE_DEBUG_UTILS_OBJECT_NAME_INFO_EXT;
info.objectType = VK_OBJECT_TYPE_INSTANCE;
info.objectHandle = (uint64_t) *(instance->getVkInstance());
info.pObjectName = "OVK Instance";
info.pNext = NULL;
PFN_vkSetDebugUtilsObjectNameEXT vkSetDebugUtilsObjectNameEXT = (PFN_vkSetDebugUtilsObjectNameEXT)vkGetInstanceProcAddr(*(instance->getVkInstance()), "vkSetDebugUtilsObjectNameEXT");
orVkOK(vkSetDebugUtilsObjectNameEXT(device, &info));

I do not see what is going wrong on the LWJGL side. Setting the name works on everything else (I think I have tested all vulkan object types now).

EDIT: I got a hs_err_pid finally. Seems hit or miss as to if it makes one (see attached)
hs_err_pid34608.log

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffa7a00cfdb, pid=34608, tid=17880
#
# JRE version: OpenJDK Runtime Environment Temurin-18+36 (18.0+36) (build 18+36)
# Java VM: OpenJDK 64-Bit Server VM Temurin-18+36 (18+36, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, shenandoah gc, windows-amd64)
# Problematic frame:
# C  [nvoglv64.dll+0x167cfdb]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# T:\outside-development\outside\dist\client_dist\hs_err_pid34608.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

EDIT 2:
Full log with LWJGL debugging enabled:
log.txt