|Summary:||vtn_vector_construct writing out of bounds when given multiple non-zero length sources|
|Product:||Mesa||Reporter:||Forrest Reiling <freiling>|
|Component:||Drivers/Vulkan/intel||Assignee:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|Status:||RESOLVED NOTOURBUG||QA Contact:||Intel 3D Bugs Mailing List <intel-3d-bugs>|
|i915 platform:||i915 features:|
|Attachments:||Invalid SPIR-V shader|
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. Cheers, 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. and > 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. -Forrest
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