Bug 94198

Summary: [HSW] segfault in copy image when copying from cubemap to 2d
Product: Mesa Reporter: Ilia Mirkin <imirkin>
Component: Drivers/DRI/i965Assignee: Ian Romanick <idr>
Status: RESOLVED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 94448    
Attachments: patch that doesn't work

Description Ilia Mirkin 2016-02-17 17:41:50 UTC
Test case 'dEQP-GLES31.functional.copy_image.non_compressed.viewclass_128_bits.rgba32f_rgba32i.cubemap_to_texture2d'..
==7653== Invalid read of size 8
==7653==    at 0xA9C2150: intel_miptree_reference (intel_mipmap_tree.c:955)
==7653==    by 0xA9CAEC9: intel_texture_view (intel_tex.c:281)
==7653==    by 0xA824CA5: make_view (meta_copy_image.c:138)
==7653==    by 0xA824CA5: _mesa_meta_CopyImageSubData_uncompressed (meta_copy_image.c:205)
==7653==    by 0xA9BE24F: intel_copy_image_sub_data (intel_copy_image.c:217)
==7653==    by 0xA66AB8E: _mesa_CopyImageSubData (copyimage.c:584)
==7653==    by 0x938090: deqp::gles31::Functional::(anonymous namespace)::CopyImageTest::copyImageIter() (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==7653==    by 0x92E305: deqp::gles31::Functional::(anonymous namespace)::CopyImageTest::iterate() (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==7653==    by 0x5A180A: deqp::gles31::TestCaseWrapper::iterate(tcu::TestCase*) (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==7653==    by 0x9C9BEE: tcu::TestSessionExecutor::iterate() (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==7653==    by 0x998998: tcu::App::iterate() (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==7653==    by 0x59D847: main (in /home/ilia/src/deqp/modules/gles31/deqp-gles31)
==7653==  Address 0x88 is not stack'd, malloc'd or (recently) free'd

It's trying to make a texture view, but I think it doesn't end up initializing things properly in the view_tex_obj? It appears that the ->mt pointer is uninitialized.
Comment 1 Jason Ekstrand 2016-02-17 18:09:45 UTC
My first guess would be that it's working on an incomplete texture and one of the cube faces is missing.  Either that, or it's just botching the silly cube face -> gl_texture_image -> cube face conversion we have to do all over the place.  But I haven't looked at it in any sort of detail.
Comment 2 Ilia Mirkin 2016-02-17 19:08:36 UTC
Looks like what's happening is that the view_tex_obj in meta_copy_image effectively becomes an incomplete cubemap texture, and the intel_texture_view logic isn't ready for that.

   _mesa_GenTextures(1, view_tex_name);
   view_tex_obj = _mesa_lookup_texture(ctx, *view_tex_name);
   view_tex_obj->Target = tex_obj->Target;
   view_tex_obj->TargetIndex = tex_obj->TargetIndex;

   *view_tex_image = _mesa_get_tex_image(ctx, view_tex_obj, tex_obj->Target, 0);
   _mesa_init_teximage_fields(*view_tex_image);

   ctx->Driver.TextureView(view_tex_obj)

but only one image of the view_tex_obj was initialized. intel_texture_view then does:

   const int numFaces = _mesa_num_tex_faces(texObj->Target);
   for (face = 0; face < numFaces; face++) {
      for (level = 0; level < numLevels; level++) {
         struct gl_texture_image *image = texObj->Image[face][level];
         struct intel_texture_image *intel_image = intel_texture_image(image);

         intel_miptree_reference(&intel_image->mt, intel_orig_tex->mt);

but while the Target is GL_TEXTURE_CUBE_MAP (and thus there are 6 faces), only one of them [the first] has been initialized. I guess the solution is to pre-initialize all of the faces in meta_copy_image.c:make_view?
Comment 3 Ilia Mirkin 2016-02-17 21:27:06 UTC
Created attachment 121820 [details] [review]
patch that doesn't work

I tried to fix this, and while this resolves the crash, the test in question still fails.
Comment 4 Ilia Mirkin 2016-03-31 04:21:42 UTC
For the record, the relevant enablement patches should be pushed now. Just need to run dEQP with MESA_EXTENSION_OVERRIDE=GL_EXT_copy_image which should allow the test in question to run.
Comment 5 Kenneth Graunke 2016-05-25 21:33:52 UTC
My recent copy image series (0f0f357b77123544ecc6c3cf50ac87b68e798d43 and earlier) ported this to BLORP on Gen6+.  We never use the meta code that crashes.

It might still be a problem on Gen4-5, but these are also dEQP-GLES31 tests that will probably never run on Gen4-5.  We should eventually shore up Gen4-5 support, but it's probably best to track that effort separately.

Marking as fixed.

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.