Bug 99465 - vtn_vector_construct writing out of bounds when given multiple non-zero length sources
Summary: vtn_vector_construct writing out of bounds when given multiple non-zero lengt...
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/intel (show other bugs)
Version: 13.0
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2017-01-19 23:46 UTC by Forrest Reiling
Modified: 2017-02-07 20:00 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Invalid SPIR-V shader (2.28 KB, text/plain)
2017-02-07 05:09 UTC, Jason Ekstrand

Note You need to log in before you can comment on or make changes to this bug.
Description Forrest Reiling 2017-01-19 23:46:31 UTC
We ran into this problem running the correctness test for the skia graphics library on Vulkan on Linux on Intel HD520, it was causing a number of memory corruption issues and  segfaults in different tests. You can reproduce the problem by running the Skia correctness tests (https://skia.org/dev/testing/testing) on their vulkan backend (https://skia.org/user/special/vulkan). This may be the cause of https://bugs.freedesktop.org/show_bug.cgi?id=97213

The solution we used (https://fuchsia-review.googlesource.com/c/17700/) was to make the total number of components in the output vector the sum of all the components in all of the input vectors. This fixes the memory corruption, but it remains unclear to us if this is the correct behavior for the compiler, which is why we havent submitted an upstream patch yet.

Let me know if you need anything else from my end on this.


Forrest Reiling
Comment 1 Jason Ekstrand 2017-01-20 05:35:22 UTC
Are you using GLSLang or generating SPIR-V directly?  Can you provide me with either the GLSL or SPIR-V for an offending shader.  Looking at he SPIR-V spec, it looks like we're doing the right thing but I need to inspect the shader manually to be sure.
Comment 2 Forrest Reiling 2017-01-20 18:22:09 UTC
Im not sure because its skia thats generating the shader and skia isn't really my jam, but I think they are using glslang at runtime. I'll look into dumping the offending SPIR-V and/or glsl sometime next week and get back to you.
Comment 3 Jason Ekstrand 2017-02-07 05:09:09 UTC
Created attachment 129377 [details]
Invalid SPIR-V shader

I've attached the invalid shader.  The second OpCompositeConstruct in the shader violates the SPIR-V spec in two ways.  It constructs a vec2 from a single vec3 but

> When constructing a vector, the total number of components in all the operands
> must equal the number of components in Result Type.


> When constructing a vector, there must be at least two Constituent operands.

Yes, we could make our SPIR-V parser handle this and it might be useful for debugging purposes, but it's definitely invalid and needs to be fixed.
Comment 4 Forrest Reiling 2017-02-07 19:21:17 UTC
Ok thanks for looking into this, I'll forward this to the Skia people so they can look into the offending shader. Sorry for sending you on a goose chase.

Comment 5 Forrest Reiling 2017-02-07 20:00:37 UTC
Opened a bug with Skia to track this issue: https://bugs.chromium.org/p/skia/issues/detail?id=6210

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.