Crash in vkCmdBindDescriptorSets2 when printf_enable is true (null pointer access)

[mklefrancois]

Environment:

• OS: Windows
• GPU and driver version: NVIDIA, Driver 581.240.0
• Vulkan API Version used: 1.4
• Vulkan SDK version: 1.4.335

Describe the Issue

A user of https://github.com/nvpro-samples/vk_raytracing_tutorial_KHR, found that enabling printf_enable in the validation layer causes a crash (null pointer access) when calling vkCmdBindDescriptorSets2. Replacing the call with vkCmdBindDescriptorSets works.

Note: The same code works correctly when printf_enable = false.

Call stack shows:

VkLayer_khronos_validation.dll!vulkan_layer_chassis::CmdBindDescriptorSets2(...) Line 9739
Access violation reading location 0x0000000000000000.

Expected behavior

Both vkCmdBindDescriptorSets2 and vkCmdBindDescriptorSets should behave the same with printf_enable.

Repro

1. Follow the Quick Start of vk_raytracing_tutorial_KHR
2. Run 01_foundation — works fine
3. Enable printf in validation settings:

Modify the code to add the printf_enable

  // Adding control on the validation layers
  nvvk::ValidationSettings validationSettings;
  validationSettings.setPreset(nvvk::ValidationSettings::LayerPresets::eStandard);
  validationSettings.printf_enable = true;
  vkSetup.instanceCreateInfoExt = validationSettings.buildPNextChain();

This will crash in vkCmdBindDescriptorSets2.

Replacing it with the following will be properly executed by the validation layer.

vkCmdBindDescriptorSets(cmd, VK_PIPELINE_BIND_POINT_GRAPHICS, m_graphicPipelineLayout, 0, 1,
                        m_descPack.getSetPtr(), 0, nullptr);

[spencer-lunarg]

@mklefrancois thanks for raising this, I will take a look

I quick wrote a test and confirmed basic usage of vkCmdBindDescriptorSets2 seems to work

TEST_F(NegativeDebugPrintf, CmdBindDescriptorSets2) {
    SetTargetApiVersion(VK_API_VERSION_1_4);
    RETURN_IF_SKIP(InitDebugPrintfFramework());
    RETURN_IF_SKIP(InitState());

    const char *shader_source = R"glsl(
        #version 450
        #extension GL_EXT_debug_printf : enable
        layout(set = 0, binding = 0) buffer SSBO {
            uint payload;
        };
        void main() {
            payload = 5;
            debugPrintfEXT("payload == %u\n", payload);
        }
    )glsl";

    vkt::Buffer buffer(*m_device, 64, VK_BUFFER_USAGE_STORAGE_BUFFER_BIT, kHostVisibleMemProps);
    ((uint32_t *)buffer.Memory().Map())[0] = 1;

    OneOffDescriptorSet descriptor_set(m_device, {{0, VK_DESCRIPTOR_TYPE_STORAGE_BUFFER, 1, VK_SHADER_STAGE_ALL, nullptr}});
    const vkt::PipelineLayout pipeline_layout(*m_device, {&descriptor_set.layout_});
    descriptor_set.WriteDescriptorBufferInfo(0, buffer, 0, VK_WHOLE_SIZE, VK_DESCRIPTOR_TYPE_STORAGE_BUFFER);
    descriptor_set.UpdateDescriptorSets();

    CreateComputePipelineHelper pipe(*this);
    pipe.cs_ = VkShaderObj(*m_device, shader_source, VK_SHADER_STAGE_COMPUTE_BIT);
    pipe.cp_ci_.layout = pipeline_layout;
    pipe.CreateComputePipeline();

    VkBindDescriptorSetsInfo bind_ds_info = vku::InitStructHelper();
    bind_ds_info.stageFlags = VK_SHADER_STAGE_COMPUTE_BIT;
    bind_ds_info.layout = pipeline_layout;
    bind_ds_info.pDescriptorSets = &descriptor_set.set_;
    bind_ds_info.dynamicOffsetCount = 0;
    bind_ds_info.pDynamicOffsets = nullptr;
    bind_ds_info.firstSet = 0;
    bind_ds_info.descriptorSetCount = 1;

    m_command_buffer.Begin();
    vk::CmdBindPipeline(m_command_buffer, VK_PIPELINE_BIND_POINT_COMPUTE, pipe);
    vk::CmdBindDescriptorSets2(m_command_buffer, &bind_ds_info);
    vk::CmdDispatch(m_command_buffer, 1, 1, 1);
    m_command_buffer.End();

    m_errorMonitor->SetDesiredInfo("payload == 5");
    m_default_queue->SubmitAndWait(m_command_buffer);
    m_errorMonitor->VerifyFound();
}

[ziga-lunarg]

Possibly related to #10458
Could be a driver bug that was fixed recently. Maybe @pdaniell-nv can confirm?

[spencer-lunarg]

@ziga-lunarg lol, I already pinged Piers, I think this is around handle wrapping, not their bug, I will just try to reproduce on my windows NVIDIA machine

[spencer-lunarg]

reproduced on older and latest (591.236.0) driver, so ya, something is wrong... looking into