Слой проверки ядра LunarG сбрасывает структуру до нуля

Я реализую базовый пример текстурированного куба и столкнулся с интересной проблемой: после передачи моей структуры DescriptorWriteSet вызову API UpdateDescriptorSets все поля были обнулены. Любой код, который пытается прочитать поля после этого, получает исключение нулевого указателя (поскольку указатель DescriptorBufferInfo теперь нулевой). Это только происходит, когда VK_LAYER_LUNARG_core_validation включен, и если я отключу его, вызов API будет работать нормально.

Мой образец неполный, поэтому я не могу сказать, работает ли он с отключенным слоем или у меня есть какая-то ошибка в моем коде. Тем не менее, я смотрел на значения, передаваемые этому вызову, выполняя проверку работоспособности, потому что я был уверен, что я не передал нулевой указатель. Это ошибка или это ожидаемое поведение?

• Windows 10
• LunarG SDK 1.0.8 (я бы хотел использовать версию 1.0.13, но для этого требуется более новый драйвер AMD, из-за которого на моем компьютере появляется синий экран)

ИЗМЕНИТЬ:

Это не просто обнуление структуры, которую я ей даю - в настоящее время я передаю только первое DescriptorWriteSet в постоянном массиве, и оно также обнуляет второе. На самом деле, когда я проверяю память вокруг массива, этот слой касается памяти с обеих сторон массива. Мне это больше похоже на баг...

РЕДАКТИРОВАТЬ 2:

Оказывается, проблема связана с моим кодом:

DescriptorSetLayoutBinding layout_bindings[]{
    DescriptorSetLayoutBinding()
        .Binding(0)
        .Descriptors(DescriptorType::UNIFORM_BUFFER, 1)
        .StageFlags(ShaderStageFlagBits::VERTEX),
    DescriptorSetLayoutBinding()
        .Binding(0)
        .Descriptors(DescriptorType::COMBINED_IMAGE_SAMPLER, 1)
        .StageFlags(ShaderStageFlagBits::FRAGMENT)
};

Обе мои привязки макета имели одинаковый индекс привязки 0. Конечно, я ожидал, что это вызовет проблемы, но я не ожидал, что это вызовет обнуление структур, передаваемых в будущих вызовах API... Я всегда не решаюсь поднять такие вещи как проблемы на Github, потому что более чем в половине случаев это моя вина, что я получаю проблему.