Wgpu-rs: STATUS_HEAP_CORRUPTION on Device::create_pipeline_layout

[Lowentwickler]

We are struggling with one issue that is only on one Windows machine. On Mac and another Windows machine it is OK.

here is the log:

RUST_LOG="warn,error,info" cargo run --release --example fox
    Finished release [optimized] target(s) in 0.48s
     Running `target\release\examples\fox.exe`
Starting Fox Skeletal Animation Example
[0.258103 INFO](Instance::pick_adapter)(wgpu_core::instance): Adapter Dx12 AdapterInfo { name: "Intel(R) HD Graphics 630", vendor: 32902, device: 22811, device_type: IntegratedGpu }
[0.281333 WARN](Adapter::request_device)(wgpu_core::instance): Missing internal features: INDEPENDENT_BLENDING | VERTEX_STORES_AND_ATOMICS | FRAGMENT_STORES_AND_ATOMICS
[0.467813 INFO](Adapter::request_device)(wgpu_core::command::allocator): Starting on (internal) thread ThreadId(1)
[0.467861 WARN](Adapter::request_device)(wgpu_core::device::alloc): max_memory_allocation_count is not set by gfx-rs backend
[0.467999 INFO](Device::create_swap_chain)(wgpu_core::device): creating swap chain SwapChainDescriptor { usage: RENDER_ATTACHMENT, format: Bgra8UnormSrgb, width: 1024, height: 768, present_mode: Mailbox }
[0.468038 WARN](Device::create_swap_chain)(wgpu_core::device): Surface does not support present mode: MAILBOX, falling back to FIFO
[0.634949 INFO](Device::create_texture)(wgpu_core::device): Created texture Valid((0, 1, Dx12)) with TextureDescriptor { label: Some("Depth Buffer"), size: Extent3d { width: 1024, height: 768, depth: 1 }, mip_level_count: 1, sample_count: 1, dimension: D2, format: Depth32Float, usage: COPY_DST | SAMPLED | RENDER_ATTACHMENT }
[0.636861 INFO]()(no module): importing skin as `Fox::fox::skin`
[0.636898 INFO](Device::create_buffer)(wgpu_core::device): Create buffer BufferDescriptor { label: Some("Uniform Buffer"), size: 68, usage: COPY_DST | UNIFORM, mapped_at_creation: true } with ID PhantomData
[0.637101 INFO]()(no module): importing mesh as `Fox::fox::mesh`
[0.637134 INFO]()(no module): importing texture as `Fox::fox::texture`
[0.662261 INFO]()(no module): importing animation as `Fox::Survey`
[0.662443 INFO]()(no module): importing animation as `Fox::Walk`
[0.662508 INFO]()(no module): importing animation as `Fox::Run`
[0.810143 INFO](Device::create_buffer)(wgpu_core::device): Created buffer Valid((0, 1, Dx12)) with BufferDescriptor { label: Some("Uniform Buffer"), size: 68, usage: COPY_DST | UNIFORM, mapped_at_creation: true }
[0.915610 WARN](Device::create_shader_module)(no module): Unknown decoration ColMajor
[0.915694 WARN](Device::create_shader_module)(no module): Unknown decoration MatrixStride
[0.915756 WARN](Device::create_shader_module)(no module): Unsupported builtin 4
[0.915868 WARN](Device::create_shader_module)(no module): Unknown decoration ColMajor
[0.915982 WARN](Device::create_shader_module)(no module): Unknown decoration MatrixStride
[0.916292 WARN](Device::create_shader_module)(wgpu_core::device): Failed to parse shader SPIR-V code: UnsupportedInstruction(Function, LogicalAnd)
[0.916366 WARN](Device::create_shader_module)(wgpu_core::device): Shader module will not be validated
[0.916454 INFO](Device::create_pipeline_layout)(no module): Creating a pipeline layout with 1 sets and 0 root constants
error: process didn't exit successfully: `target\release\examples\fox.exe` (exit code: 0xc0000374, STATUS_HEAP_CORRUPTION)

The failure happens on a call to device.create_render_pipeline

And I believe it is connected to one specificBindGroupLayoutEntry

                wgpu::BindGroupLayoutEntry {
                    binding: 4,
                    visibility: wgpu::ShaderStage::VERTEX,
                    ty: wgpu::BindingType::Buffer {
                        ty: wgpu::BufferBindingType::Uniform,
                        has_dynamic_offset: false,
                        min_binding_size: None,
                    },
                    count: None,
                },

But at this moment I have no more ideas how to debug it, so any help is welcome.
Happens in 0.6.0, 0.6.2 and in master too (tried to update recently)

[kvark]

Could you please record an API trace and attach a zip of it here?

If that's not possible, maybe you can share a reproducible case for us in code?

Another thing that would help is running that app from Visual Studio and seeing what D3D validation errors show up in the console.

[Lowentwickler]

here it is wgpu-trace.zip

In this branch, there is an example that could be run with
cargo run --release --example fox

But as I said, it works on several machines, and fails on one.

[kvark]

Thank you! If we are not able to reproduce, it would be very helpful to see that windows debug log (e.g. from Visual Studio).

[Lowentwickler]

VS_Output.txt
@kvark By the VS logs you mean these ones?

[kvark]

Yeah, this log would show any validation issues from D3d12 perspective. I tried reproducing it on a Windows/Intel laptop. Unable to run the fox example due to https://github.com/lowenware/dotrix/issues/21. Able to replay the API trace, but it doesn't crash or show anything abnormal.

[Lowentwickler]

It seems, that fail somehow caused by the BindGroupLayoutEntry I've mentioned. And in the vertex shader it refers these uniform

const int MAX_JOINTS = 32;
...
layout(set = 0, binding = 4) uniform JointMatrices {
    mat4 u_JointMatrix[MAX_JOINTS];
};

Just a thought, but Is it legal to have min_binding_size: None, there?

[kvark]

It's always legal to have min_binding_size: None, and currently we aren't doing anything about it.
Does your buffer have enough space for this binding? The binding size is supposed to be at least 32 * 4 *4 * 4 = 2048 bytes

[Lowentwickler]

the failure happens on create_render_pipeline before I can pass anything to uniforms.

[Lowentwickler]

We've tried to run the same code on the same machine but using .spv shaders compiled with glslang and it worked just fine. The issue is most likely somewhere on shaderc side. I decided to keep shaderc as a feature just for shader`s developement cases. So I think this issue can be closed.

[cwfitzgerald]

Does the backtrace show spirv-cross? I had a similar issue with shaderc 0.7: https://github.com/BVE-Reborn/rend3/issues/1

[Lowentwickler]

@cwfitzgerald

[0.810143 INFO](Device::create_buffer)(wgpu_core::device): Created buffer Valid((0, 1, Dx12)) with BufferDescriptor { label: Some("Uniform Buffer"), size: 68, usage: COPY_DST | UNIFORM, mapped_at_creation: true }
[0.915610 WARN](Device::create_shader_module)(no module): Unknown decoration ColMajor
[0.915694 WARN](Device::create_shader_module)(no module): Unknown decoration MatrixStride
[0.915756 WARN](Device::create_shader_module)(no module): Unsupported builtin 4
[0.915868 WARN](Device::create_shader_module)(no module): Unknown decoration ColMajor
[0.915982 WARN](Device::create_shader_module)(no module): Unknown decoration MatrixStride
[0.916292 WARN](Device::create_shader_module)(wgpu_core::device): Failed to parse shader SPIR-V code: UnsupportedInstruction(Function, LogicalAnd)
[0.916366 WARN](Device::create_shader_module)(wgpu_core::device): Shader module will not be validated
[0.916454 INFO](Device::create_pipeline_layout)(no module): Creating a pipeline layout with 1 sets and 0 root constants

Backtrace was not showing much. But above are some catches from LOG module, that made me think, that shaders are not properly compiled. Because on other machines, there are no such messages

[cwfitzgerald]

That's all naga stuff which is optional and on the front end. It's only used for reflection, not transpiling. Does the problem go away when you use shaderc 0.6?