Summary: | gles cts-runner segfault compiling shader with textureGatherOffsets | ||
---|---|---|---|
Product: | Mesa | Reporter: | Mark Janes <mark.a.janes> |
Component: | Drivers/DRI/i965 | Assignee: | Tapani Pälli <lemody> |
Status: | RESOLVED DUPLICATE | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | Keywords: | bisected, regression |
Version: | 19.1 | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | backtrace and shader text from crashing compile |
624789e3708c87ea2a4c8d2266266b489b421cba is the first bad commit commit 624789e3708c87ea2a4c8d2266266b489b421cba Author: Tapani Pälli <tapani.palli@intel.com> Date: Fri Mar 15 09:47:49 2019 +0200 compiler/glsl: handle case where we have multiple users for types Both Vulkan and OpenGL might be using glsl_types simultaneously or we can also have multiple concurrent Vulkan instances using glsl_types. Patch adds a one time init to track number of users and will release types only when last user calls _glsl_type_singleton_decref(). This change fixes glsl_type memory leaks we have with anv driver. v2: reuse hash_mutex, cleanup, apply fix also to radv driver and rename helper functions (Jason) v3: move init, destroy to happen on GL context init and destroy Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com> Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> I'll daresay this is a duplicate of bug 110796. *** This bug has been marked as a duplicate of bug 110796 *** (In reply to Mark Janes from comment #0) > Created attachment 144770 [details] > backtrace and shader text from crashing compile > > When running the gles cts on mesa master, the test runner segfaults on tests > which pass when run individually. The same test will crash reliably via > cts-runner, but running the same config via the glcts executable will pass. > > It takes about an hour on a kblgt3 to encounter the segfault, but this can > be accelerated by emptying out the test lists for various configs so that > cts-runner executes only the tests in > gl_cts/data/mustpass/gles/khronos_mustpass/3.2.5.x/gles31-khr-master.txt Mark, can you advice how to do this? I've tried to edit the xml files but it still seems to run EGL, GLES2 tests etc .. (In reply to Tapani Pälli from comment #3) > (In reply to Mark Janes from comment #0) > > Created attachment 144770 [details] > > backtrace and shader text from crashing compile > > > > When running the gles cts on mesa master, the test runner segfaults on tests > > which pass when run individually. The same test will crash reliably via > > cts-runner, but running the same config via the glcts executable will pass. > > > > It takes about an hour on a kblgt3 to encounter the segfault, but this can > > be accelerated by emptying out the test lists for various configs so that > > cts-runner executes only the tests in > > gl_cts/data/mustpass/gles/khronos_mustpass/3.2.5.x/gles31-khr-master.txt > > Mark, can you advice how to do this? I've tried to edit the xml files but it > still seems to run EGL, GLES2 tests etc .. I think I got it, need to edit txt files instead |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 144770 [details] backtrace and shader text from crashing compile When running the gles cts on mesa master, the test runner segfaults on tests which pass when run individually. The same test will crash reliably via cts-runner, but running the same config via the glcts executable will pass. It takes about an hour on a kblgt3 to encounter the segfault, but this can be accelerated by emptying out the test lists for various configs so that cts-runner executes only the tests in gl_cts/data/mustpass/gles/khronos_mustpass/3.2.5.x/gles31-khr-master.txt Regardless of what test is crashing, the stack trace is the same (attached). The compiler is attempting to format an error because it cannot find a matching function for a textureGatherOffsets invocation. The parameter type list in the ast has a corrupted type member, which can be seen in gdb. Running valgrind on the cts-runner does not find memory errors, but the test fails instead of segfaulting. I was unable to bisect mesa because cts-runner fails to run on older commits (eg 18.3). I applied a patch to cts to disable broken 565 configs, which did not help the suite to run.