Bug 93790 - [HSW] Use after free with compute programs
Summary: [HSW] Use after free with compute programs
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Kenneth Graunke
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-20 13:43 UTC by Ilia Mirkin
Modified: 2016-02-18 03:40 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ilia Mirkin 2016-01-20 13:43:57 UTC
When running the upstream dEQP GLES31 testsuite, I see the following with valgrind. Note that this is with a tree that includes f8ac314cc23 (i965: Implement compute sampler state atom).

==9129== Invalid read of size 4
==9129==    at 0xA9BCA19: update_stage_texture_surfaces (brw_wm_surface_state.c:840)
==9129==    by 0xA9BCB1A: brw_update_texture_surfaces (brw_wm_surface_state.c:879)
==9129==    by 0xA9B502E: check_and_emit_atom (brw_state_upload.c:771)
==9129==    by 0xA9B502E: brw_upload_pipeline_state (brw_state_upload.c:882)
==9129==    by 0xA9B502E: brw_upload_compute_state (brw_state_upload.c:942)
==9129==    by 0xA9929B7: brw_dispatch_compute_common.part.2 (brw_compute.c:140)
==9129==    by 0xA68E34B: _mesa_DispatchCompute (compute.c:44)
==9129==    by 0xCA3545: deqp::gls::ShaderExecUtil::ComputeShaderExecutor::execute(int, void const* const*, void* const*) (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==    by 0x6F7638: deqp::gles31::Functional::CommonFunctionCase::iterate() (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==    by 0x5A180A: deqp::gles31::TestCaseWrapper::iterate(tcu::TestCase*) (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==    by 0x9C9BEE: tcu::TestSessionExecutor::iterate() (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==    by 0x998998: tcu::App::iterate() (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==    by 0x59D847: main (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==  Address 0xd3e8ca4 is 884 bytes inside a block of size 1,040 free'd
==9129==    at 0x4C2B1DC: free (vg_replace_malloc.c:473)
==9129==    by 0xA86E563: _mesa_reference_program_ (program.c:336)
==9129==    by 0xA765282: _mesa_reference_program (program.h:89)
==9129==    by 0xA765282: _mesa_reference_vertprog (program.h:97)
==9129==    by 0xA765282: update_program (state.c:225)
==9129==    by 0xA765282: _mesa_update_state_locked (state.c:473)
==9129==    by 0xA765308: _mesa_update_state (state.c:504)
==9129==    by 0xA992E47: brw_dispatch_compute_common.part.2 (brw_compute.c:118)
==9129==    by 0xA68E34B: _mesa_DispatchCompute (compute.c:44)
==9129==    by 0xCA3545: deqp::gls::ShaderExecUtil::ComputeShaderExecutor::execute(int, void const* const*, void* const*) (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==    by 0x6F7638: deqp::gles31::Functional::CommonFunctionCase::iterate() (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==    by 0x5A180A: deqp::gles31::TestCaseWrapper::iterate(tcu::TestCase*) (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==    by 0x9C9BEE: tcu::TestSessionExecutor::iterate() (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==    by 0x998998: tcu::App::iterate() (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==9129==    by 0x59D847: main (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)

It doesn't happen when running just one test individually, you have to run a bunch. What I do is

1. Clone https://android.googlesource.com/platform/external/deqp
2. Apply this patch:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9760d72..0e7455c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -66,8 +66,8 @@ endif ()
 include_directories(${ZLIB_INCLUDE_PATH})
 
 # libpng
-find_path(PNG_INCLUDE_PATH     libpng.h)
-find_library(PNG_LIBRARY       png)
+find_path(PNG_INCLUDE_PATH     png.h)
+find_package(PNG)
 
 if (NOT PNG_INCLUDE_PATH OR NOT PNG_LIBRARY)
        message(STATUS "System version of libpng not found, using external/libpng")
diff --git a/framework/platform/X11/tcuX11GlxPlatform.cpp b/framework/platform/X11/tcuX11GlxPlatform.cpp
index 1f9e9bc..87e263b 100644
--- a/framework/platform/X11/tcuX11GlxPlatform.cpp
+++ b/framework/platform/X11/tcuX11GlxPlatform.cpp
@@ -322,11 +322,11 @@ GLXContext GlxVisual::createContext (const GlxContextFactory&     factory,
 
        const int attribs[] =
        {
-               GLX_CONTEXT_MAJOR_VERSION_ARB,  apiType.getMajorVersion(),
-               GLX_CONTEXT_MINOR_VERSION_ARB,  apiType.getMinorVersion(),
+               GLX_CONTEXT_MAJOR_VERSION_ARB,  2,
+               GLX_CONTEXT_MINOR_VERSION_ARB,  0,
                GLX_CONTEXT_FLAGS_ARB,                  0,
                GLX_CONTEXT_PROFILE_MASK_ARB,   profileMask,
-               None
+               0
        };
        return TCU_CHECK_GLX(factory.m_glXCreateContextAttribsARB(
                                                         getXDisplay(), m_fbConfig, DE_NULL, True, attribs));

3. cmake -DDEQP_TARGET=x11_egl_glx; make -j8
4. cd modules/gles31; MESA_GLES_VERSION_OVERRIDE=3.1 valgrind ./deqp-gles31 --deqp-visibility=hidden |& tee i965-valgrind.log

You should see the above backtraces within a minute or so.
Comment 1 Ilia Mirkin 2016-01-20 13:48:12 UTC
Looks like this is usually enough to trigger it:

--deqp-case=dEQP-GLES31.functional.shaders.builtin_functions.common.frexp.float_lowp_*

First it runs the tests in the frag shader, then compute. The switch causes problems I guess?
Comment 2 Ilia Mirkin 2016-01-21 19:28:02 UTC
IMHO this is a pretty serious bug... just repro'd with

bin/arb_shader_image_load_store-semantics -fbo -auto

Program received signal SIGSEGV, Segmentation fault.
update_stage_texture_surfaces (brw=brw@entry=0x7ffff7fcf040, prog=prog@entry=0xd62340, 
    stage_state=stage_state@entry=0x7ffff7ff3cf0, for_gather=for_gather@entry=true) at brw_wm_surface_state.c:842
842           surf_offset[s] = 0;
(gdb) bt
#0  update_stage_texture_surfaces (brw=brw@entry=0x7ffff7fcf040, prog=prog@entry=0xd62340, 
    stage_state=stage_state@entry=0x7ffff7ff3cf0, for_gather=for_gather@entry=true) at brw_wm_surface_state.c:842
#1  0x00007ffff03d5bb4 in brw_update_texture_surfaces (brw=0x7ffff7fcf040) at brw_wm_surface_state.c:891
#2  0x00007ffff03cdf4f in check_and_emit_atom (atom=0x7ffff7ff5610, state=<synthetic pointer>, brw=0x7ffff7fcf040)
    at brw_state_upload.c:771
#3  brw_upload_pipeline_state (pipeline=BRW_COMPUTE_PIPELINE, brw=0x7ffff7fcf040) at brw_state_upload.c:882
#4  brw_upload_compute_state (brw=0x7ffff7fcf040) at brw_state_upload.c:942

(gdb) p *stage_state->prog_data
$2 = {binding_table = {size_bytes = 12, pull_constants_start = 3, texture_start = 1, gather_texture_start = 3503345872, 
    ubo_start = 1, ssbo_start = 1, abo_start = 3503345872, image_start = 1, shader_time_start = 3503345872}, nr_params = 2, 
  nr_pull_params = 0, nr_image_params = 2, curb_read_length = 1, total_scratch = 0, total_shared = 0, dispatch_grf_start_reg = 4, 
  use_alt_mode = false, param = 0xc9f3a0, pull_param = 0x10ef6a0, image_param = 0x10d9070}

which is the same thing as the valgrind complaint. The texgather value gets overwritten with 0xd0d0d0d0 (consistently so, it seems) and so the surf_offset is out in la-la land. But the underlying issue appears to be the use-after-free.
Comment 3 Ian Romanick 2016-01-21 20:49:21 UTC
Curro and Jordan: Can one of you guys look into this?  I don't have a HSW system, and the piglit test mentioned in comment #2 is fine on my BDW.

Mark: How does that piglit test fare on the CI?
Comment 4 Ilia Mirkin 2016-01-21 20:57:31 UTC
(In reply to Ian Romanick from comment #3)
> I don't have a HSW
> system, and the piglit test mentioned in comment #2 is fine on my BDW.

I suspect that's because you don't have ARB_compute_shader enabled on there, due to the invocation situation/lack-of-SIMD32.
Comment 5 Mark Janes 2016-01-21 20:59:22 UTC
I have not seen piglit.spec.arb_shader_image_load_store.semantics fail since it was fixed in piglit 9bd8454
Comment 6 Ilia Mirkin 2016-01-21 21:06:42 UTC
(In reply to Mark Janes from comment #5)
> I have not seen piglit.spec.arb_shader_image_load_store.semantics fail since
> it was fixed in piglit 9bd8454

OK, well I'm at the latest piglit, here's the rest of my system:

Mesa commit daa0fd7843df

00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)

./configure --prefix=/home/ilia/install --with-dri-drivers=i965,nouveau --with-gallium-drivers=nouveau,swrast --enable-gallium-llvm --enable-gles1 --enable-gles2 --with-egl-platforms=drm,x11 --enable-texture-float --enable-debug CFLAGS='-fno-omit-frame-pointer -O2 -g' CXXFLAGS='-fno-omit-frame-pointer -O2 -g'

LD_LIBRARY_PATH=/home/ilia/install/lib64:/home/ilia/install/lib valgrind bin/arb_shader_image_load_store-semantics -fbo -auto
... lots of output ....
PIGLIT: {"subtest": {"imageStore/Compute shader/r8i/image1D test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/r8i/image2D test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/r8i/image3D test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/r8i/image2DRect test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/r8i/imageCube test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/r8i/imageBuffer test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/r8i/image1DArray test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/r8i/image2DArray test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/r8i/imageCubeArray test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgba16/image1D test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgba16/image2D test" : "pass"}}
==12712== Invalid read of size 4
==12712==    at 0xCB75549: get_pipeline_state_l3_weights (gen7_l3_state.c:311)
==12712==    by 0xCB75549: emit_l3_state (gen7_l3_state.c:480)
==12712==    by 0xCB5B87E: check_and_emit_atom (brw_state_upload.c:771)
==12712==    by 0xCB5B87E: brw_upload_pipeline_state (brw_state_upload.c:882)
==12712==    by 0xCB5B87E: brw_upload_compute_state (brw_state_upload.c:942)
==12712==    by 0xCB39207: brw_dispatch_compute_common.part.2 (brw_compute.c:140)
==12712==    by 0xC83501B: _mesa_DispatchCompute (compute.c:44)
==12712==    by 0x406135: draw_grid (grid.c:349)
==12712==    by 0x403A65: run_test (semantics.c:337)
==12712==    by 0x403BBD: piglit_init (semantics.c:368)
==12712==    by 0x4F6F75D: run_test (piglit_fbo_framework.c:50)
==12712==    by 0x4F55AC4: piglit_gl_test_run (piglit-framework-gl.c:199)
==12712==    by 0x402E20: main (semantics.c:55)
==12712==  Address 0xe4a1cf4 is 212 bytes inside a block of size 512 free'd
==12712==    at 0x4C2B1DC: free (vg_replace_malloc.c:473)
==12712==    by 0xCB57C10: brw_clear_cache (brw_state_cache.c:374)
==12712==    by 0xC83501B: _mesa_DispatchCompute (compute.c:44)
==12712==    by 0x406135: draw_grid (grid.c:349)
==12712==    by 0x403A65: run_test (semantics.c:337)
==12712==    by 0x403BBD: piglit_init (semantics.c:368)
==12712==    by 0x4F6F75D: run_test (piglit_fbo_framework.c:50)
==12712==    by 0x4F55AC4: piglit_gl_test_run (piglit-framework-gl.c:199)
==12712==    by 0x402E20: main (semantics.c:55)
==12712== 
==12712== Invalid read of size 4
==12712==    at 0xCB75551: get_pipeline_state_l3_weights (gen7_l3_state.c:311)
==12712==    by 0xCB75551: emit_l3_state (gen7_l3_state.c:480)
==12712==    by 0xCB5B87E: check_and_emit_atom (brw_state_upload.c:771)
==12712==    by 0xCB5B87E: brw_upload_pipeline_state (brw_state_upload.c:882)
==12712==    by 0xCB5B87E: brw_upload_compute_state (brw_state_upload.c:942)
==12712==    by 0xCB39207: brw_dispatch_compute_common.part.2 (brw_compute.c:140)
==12712==    by 0xC83501B: _mesa_DispatchCompute (compute.c:44)
==12712==    by 0x406135: draw_grid (grid.c:349)
==12712==    by 0x403A65: run_test (semantics.c:337)
==12712==    by 0x403BBD: piglit_init (semantics.c:368)
==12712==    by 0x4F6F75D: run_test (piglit_fbo_framework.c:50)
==12712==    by 0x4F55AC4: piglit_gl_test_run (piglit-framework-gl.c:199)
==12712==    by 0x402E20: main (semantics.c:55)
==12712==  Address 0xe4a1cec is 204 bytes inside a block of size 512 free'd
==12712==    at 0x4C2B1DC: free (vg_replace_malloc.c:473)
==12712==    by 0xCB57C10: brw_clear_cache (brw_state_cache.c:374)
==12712==    by 0xC83501B: _mesa_DispatchCompute (compute.c:44)
==12712==    by 0x406135: draw_grid (grid.c:349)
==12712==    by 0x403A65: run_test (semantics.c:337)
==12712==    by 0x403BBD: piglit_init (semantics.c:368)
==12712==    by 0x4F6F75D: run_test (piglit_fbo_framework.c:50)
==12712==    by 0x4F55AC4: piglit_gl_test_run (piglit-framework-gl.c:199)
==12712==    by 0x402E20: main (semantics.c:55)
==12712== 
==12712== Invalid read of size 4
==12712==    at 0xCB7550A: get_pipeline_state_l3_weights (gen7_l3_state.c:312)
==12712==    by 0xCB7550A: emit_l3_state (gen7_l3_state.c:480)
==12712==    by 0xCB5B87E: check_and_emit_atom (brw_state_upload.c:771)
==12712==    by 0xCB5B87E: brw_upload_pipeline_state (brw_state_upload.c:882)
==12712==    by 0xCB5B87E: brw_upload_compute_state (brw_state_upload.c:942)
==12712==    by 0xCB39207: brw_dispatch_compute_common.part.2 (brw_compute.c:140)
==12712==    by 0xC83501B: _mesa_DispatchCompute (compute.c:44)
==12712==    by 0x406135: draw_grid (grid.c:349)
==12712==    by 0x403A65: run_test (semantics.c:337)
==12712==    by 0x403BBD: piglit_init (semantics.c:368)
==12712==    by 0x4F6F75D: run_test (piglit_fbo_framework.c:50)
==12712==    by 0x4F55AC4: piglit_gl_test_run (piglit-framework-gl.c:199)
==12712==    by 0x402E20: main (semantics.c:55)
==12712==  Address 0xe4a1cf8 is 216 bytes inside a block of size 512 free'd
==12712==    at 0x4C2B1DC: free (vg_replace_malloc.c:473)
==12712==    by 0xCB57C10: brw_clear_cache (brw_state_cache.c:374)
==12712==    by 0xC83501B: _mesa_DispatchCompute (compute.c:44)
==12712==    by 0x406135: draw_grid (grid.c:349)
==12712==    by 0x403A65: run_test (semantics.c:337)
==12712==    by 0x403BBD: piglit_init (semantics.c:368)
==12712==    by 0x4F6F75D: run_test (piglit_fbo_framework.c:50)
==12712==    by 0x4F55AC4: piglit_gl_test_run (piglit-framework-gl.c:199)
==12712==    by 0x402E20: main (semantics.c:55)
==12712== 
==12712== Invalid read of size 4
==12712==    at 0xCB63262: update_stage_texture_surfaces (brw_wm_surface_state.c:838)
==12712==    by 0xCB6336A: brw_update_texture_surfaces (brw_wm_surface_state.c:879)
==12712==    by 0xCB5B87E: check_and_emit_atom (brw_state_upload.c:771)
==12712==    by 0xCB5B87E: brw_upload_pipeline_state (brw_state_upload.c:882)
==12712==    by 0xCB5B87E: brw_upload_compute_state (brw_state_upload.c:942)
==12712==    by 0xCB39207: brw_dispatch_compute_common.part.2 (brw_compute.c:140)
==12712==    by 0xC83501B: _mesa_DispatchCompute (compute.c:44)
==12712==    by 0x406135: draw_grid (grid.c:349)
==12712==    by 0x403A65: run_test (semantics.c:337)
==12712==    by 0x403BBD: piglit_init (semantics.c:368)
==12712==    by 0x4F6F75D: run_test (piglit_fbo_framework.c:50)
==12712==    by 0x4F55AC4: piglit_gl_test_run (piglit-framework-gl.c:199)
==12712==    by 0x402E20: main (semantics.c:55)
==12712==  Address 0xe4a1cc8 is 168 bytes inside a block of size 512 free'd
==12712==    at 0x4C2B1DC: free (vg_replace_malloc.c:473)
==12712==    by 0xCB57C10: brw_clear_cache (brw_state_cache.c:374)
==12712==    by 0xC83501B: _mesa_DispatchCompute (compute.c:44)
==12712==    by 0x406135: draw_grid (grid.c:349)
==12712==    by 0x403A65: run_test (semantics.c:337)
==12712==    by 0x403BBD: piglit_init (semantics.c:368)
==12712==    by 0x4F6F75D: run_test (piglit_fbo_framework.c:50)
==12712==    by 0x4F55AC4: piglit_gl_test_run (piglit-framework-gl.c:199)
==12712==    by 0x402E20: main (semantics.c:55)
==12712== 
==12712== Invalid read of size 4
==12712==    at 0xCB63262: update_stage_texture_surfaces (brw_wm_surface_state.c:838)
==12712==    by 0xCB633DB: brw_update_texture_surfaces (brw_wm_surface_state.c:883)
==12712==    by 0xCB5B87E: check_and_emit_atom (brw_state_upload.c:771)
==12712==    by 0xCB5B87E: brw_upload_pipeline_state (brw_state_upload.c:882)
==12712==    by 0xCB5B87E: brw_upload_compute_state (brw_state_upload.c:942)
==12712==    by 0xCB39207: brw_dispatch_compute_common.part.2 (brw_compute.c:140)
==12712==    by 0xC83501B: _mesa_DispatchCompute (compute.c:44)
==12712==    by 0x406135: draw_grid (grid.c:349)
==12712==    by 0x403A65: run_test (semantics.c:337)
==12712==    by 0x403BBD: piglit_init (semantics.c:368)
==12712==    by 0x4F6F75D: run_test (piglit_fbo_framework.c:50)
==12712==    by 0x4F55AC4: piglit_gl_test_run (piglit-framework-gl.c:199)
==12712==    by 0x402E20: main (semantics.c:55)
==12712==  Address 0xe47b240 is 160 bytes inside a block of size 520 free'd
==12712==    at 0x4C2B1DC: free (vg_replace_malloc.c:473)
==12712==    by 0xCB57C10: brw_clear_cache (brw_state_cache.c:374)
==12712==    by 0xC83501B: _mesa_DispatchCompute (compute.c:44)
==12712==    by 0x406135: draw_grid (grid.c:349)
==12712==    by 0x403A65: run_test (semantics.c:337)
==12712==    by 0x403BBD: piglit_init (semantics.c:368)
==12712==    by 0x4F6F75D: run_test (piglit_fbo_framework.c:50)
==12712==    by 0x4F55AC4: piglit_gl_test_run (piglit-framework-gl.c:199)
==12712==    by 0x402E20: main (semantics.c:55)
==12712== 
PIGLIT: {"subtest": {"imageStore/Compute shader/rgba16/image3D test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgba16/image2DRect test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgba16/imageCube test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgba16/imageBuffer test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgba16/image1DArray test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgba16/image2DArray test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgba16/imageCubeArray test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgb10_a2/image1D test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgb10_a2/image2D test" : "pass"}}
PIGLIT: {"subtest": {"imageStore/Compute shader/rgb10_a2/image3D test" : "pass"}}


So it hardly happens every draw. I don't know what triggers it... (Also this is not the first time I see the l3 thing, but it doesn't happen each time either.)
Comment 7 Francisco Jerez 2016-01-21 22:36:30 UTC
Nice, something's apparently freeing the brw_stage_prog_data struct for some stage (brw_state_cache_check_size() maybe?) and leaving dangling pointers pointing at it.
Comment 8 Ian Romanick 2016-01-21 22:37:46 UTC
(In reply to Ilia Mirkin from comment #4)
> (In reply to Ian Romanick from comment #3)
> > I don't have a HSW
> > system, and the piglit test mentioned in comment #2 is fine on my BDW.
> 
> I suspect that's because you don't have ARB_compute_shader enabled on there,
> due to the invocation situation/lack-of-SIMD32.

I don't get the segfault even if I run with MESA_EXTENSION_OVERRIDE=+GL_ARB_compute_shader.  I haven't tried it with valgrind yet.  My tree is at 739ac3d3.
Comment 9 Ilia Mirkin 2016-01-21 23:00:36 UTC
(In reply to Ian Romanick from comment #8)
> (In reply to Ilia Mirkin from comment #4)
> > (In reply to Ian Romanick from comment #3)
> > > I don't have a HSW
> > > system, and the piglit test mentioned in comment #2 is fine on my BDW.
> > 
> > I suspect that's because you don't have ARB_compute_shader enabled on there,
> > due to the invocation situation/lack-of-SIMD32.
> 
> I don't get the segfault even if I run with
> MESA_EXTENSION_OVERRIDE=+GL_ARB_compute_shader.  I haven't tried it with
> valgrind yet.  My tree is at 739ac3d3.

On the off chance it matters, I'm using "gcc version 4.9.3 (Gentoo 4.9.3 p1.2, pie-0.6.3)" to build everything. x86_64 (not that there are a ton of haswell gpu's on arm devices...)
Comment 10 Kenneth Graunke 2016-02-10 00:51:48 UTC
Patches on the mailing list:

https://lists.freedesktop.org/archives/mesa-dev/2016-February/107141.html
https://lists.freedesktop.org/archives/mesa-dev/2016-February/107142.html
https://lists.freedesktop.org/archives/mesa-dev/2016-February/107143.html
https://lists.freedesktop.org/archives/mesa-dev/2016-February/107144.html

I think this should fix the problem.  I tested on Broadwell with:

MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader valgrind bin/arb_shader_image_load_store-semantics -fbo -auto --quick

and saw valgrind errors before these patches, and none after.  I haven't tried running dEQP through valgrind, though.
Comment 11 Alejandro Piñeiro (freenode IRC: apinheiro) 2016-02-16 11:28:18 UTC
(In reply to Kenneth Graunke from comment #10)
> Patches on the mailing list:
> 
> https://lists.freedesktop.org/archives/mesa-dev/2016-February/107141.html
> https://lists.freedesktop.org/archives/mesa-dev/2016-February/107142.html
> https://lists.freedesktop.org/archives/mesa-dev/2016-February/107143.html
> https://lists.freedesktop.org/archives/mesa-dev/2016-February/107144.html

As those are already on master, and just in case people didn't have time to test again this bug...

> 
> I think this should fix the problem.  I tested on Broadwell with:
> 
> MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader valgrind
> bin/arb_shader_image_load_store-semantics -fbo -auto --quick
> 
> and saw valgrind errors before these patches, and none after.  I haven't
> tried running dEQP through valgrind, though.

... I tried the scenarios pointed at comment #0 and at comment #1 on haswell. Although there are still some valgrind warnings, the one pointed by the bug (use after free, example "Address 0xd3e8ca4 is 884 bytes inside a block of size 1,040 free'd") are gone. 

So probably it is safe to close the bug now. Will let Ilia give the final word.
Comment 12 Ilia Mirkin 2016-02-18 03:40:39 UTC
(In reply to Alejandro Piñeiro (freenode IRC: apinheiro) from comment #11)
> (In reply to Kenneth Graunke from comment #10)
> > I think this should fix the problem.  I tested on Broadwell with:
> > 
> > MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader valgrind
> > bin/arb_shader_image_load_store-semantics -fbo -auto --quick
> > 
> > and saw valgrind errors before these patches, and none after.  I haven't
> > tried running dEQP through valgrind, though.
> 
> ... I tried the scenarios pointed at comment #0 and at comment #1 on
> haswell. Although there are still some valgrind warnings, the one pointed by
> the bug (use after free, example "Address 0xd3e8ca4 is 884 bytes inside a
> block of size 1,040 free'd") are gone. 
> 
> So probably it is safe to close the bug now. Will let Ilia give the final
> word.

Hm, I don't think I saw any valgrind warnings... this is fixed as far as I'm concerned, thanks guys!


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