Bug 93790

Summary: [HSW] Use after free with compute programs
Product: Mesa Reporter: Ilia Mirkin <imirkin>
Component: Drivers/DRI/i965Assignee: Kenneth Graunke <kenneth>
Status: RESOLVED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium CC: apinheiro, currojerez, idr, jljusten, mark.a.janes
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

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. How we collect and use information is described in our Privacy Policy.