Bug 99231 - [HSW][i965] Crash in upload_3dstate_streamout()
Summary: [HSW][i965] Crash in upload_3dstate_streamout()
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
Depends on:
Reported: 2016-12-30 18:26 UTC by Shawn Starr
Modified: 2016-12-30 23:48 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Shawn Starr 2016-12-30 18:26:13 UTC
I'm unable to run KDE or GNOME, DRI driver crashes with this:

Thread 1 "plasmashell" received signal SIGSEGV, Segmentation fault.
0x00007fff41ebdce4 in upload_3dstate_streamout () from /usr/lib64/dri/i965_dri.so
(gdb) bt full
#0  0x00007fff41ebdce4 in upload_3dstate_streamout () at /usr/lib64/dri/i965_dri.so
#1  0x00007fff41ebe0e4 in upload_sol_state () at /usr/lib64/dri/i965_dri.so
#2  0x00007fff41ea4c7b in check_and_emit_atom () at /usr/lib64/dri/i965_dri.so
#3  0x00007fff41ea51ba in brw_upload_pipeline_state () at /usr/lib64/dri/i965_dri.so
#4  0x00007fff41ea5297 in brw_upload_render_state () at /usr/lib64/dri/i965_dri.so
#5  0x00007fff41e86f97 in brw_try_draw_prims () at /usr/lib64/dri/i965_dri.so
#6  0x00007fff41e873f6 in brw_draw_prims () at /usr/lib64/dri/i965_dri.so
#7  0x00007fff41bb5905 in vbo_draw_arrays () at /usr/lib64/dri/i965_dri.so
#8  0x00007fff41bb6006 in vbo_exec_DrawArrays () at /usr/lib64/dri/i965_dri.so
#9  0x00007fff41bb7af8 in _mesa_DrawArrays () at /usr/lib64/dri/i965_dri.so
#10 0x00007fff41c6e222 in meta_clear () at /usr/lib64/dri/i965_dri.so
#11 0x00007fff41c6d5e8 in _mesa_meta_glsl_Clear () at /usr/lib64/dri/i965_dri.so
#12 0x00007fff41e7216f in brw_clear () at /usr/lib64/dri/i965_dri.so
#13 0x00007fff419eeffd in _mesa_Clear () at /usr/lib64/dri/i965_dri.so
Comment 1 Shawn Starr 2016-12-30 18:26:38 UTC
Mesa Master Dec 29th sources
Comment 2 Shawn Starr 2016-12-30 19:41:11 UTC
BAD commit:

700bc94dcebf4257740483d2ba467b138234fa1a is the first bad commit
commit 700bc94dcebf4257740483d2ba467b138234fa1a
Author: Timothy Arceri <timothy.arceri@collabora.com>
Date:   Thu Nov 3 16:00:37 2016 +1100

    mesa/glsl: move LinkedTransformFeedback from gl_shader_program to gl_program
    This will help allow us to store gl_program in the CurrentProgram array rather
    than gl_shader_program which will allow a bunch of simplifications.
    Note that we make LinkedTransformFeedback a pointer so we don't waste
    memory creating a struct for each stage. We also store a pointer to
    the gl_program that will contain the pointer in gl_shader_program so
    we can get easy access to the correct stage.
    Reviewed-by: Eric Anholt <eric@anholt.net>                                                                                                                              
:040000 040000 68eb9819c2961ed8a86d3c8cf5097352e7522145 db26c465e61f3f6b02bbb082fd7f8e75fcbccfd9 M      src                                                            

git bisect start
# bad: [36c648b894cfdf6471221d57504f9ba99b83cd41] spirv: always expose SpvCapabilityStorageImageExtendedFormats
git bisect bad 36c648b894cfdf6471221d57504f9ba99b83cd41
# good: [7a4ea95f1c5257e79a7a207eccff81c558c04d46] radeonsi: Bugfix needed for hashcat
git bisect good 7a4ea95f1c5257e79a7a207eccff81c558c04d46
# good: [75252826e82ffa9c091ebe5bcf303c9d7569c3a3] anv: return count of queue families written
git bisect good 75252826e82ffa9c091ebe5bcf303c9d7569c3a3
# good: [0de6f6223ab917ec532e3fe3afd14f8f5cd3b87b] mesa/compiler: add stage to shader_info
git bisect good 0de6f6223ab917ec532e3fe3afd14f8f5cd3b87b
# bad: [8417bf528eb155028d56acaa4cbe05eb3536093b] mesa/glsl: move BlendSupport bitfield to gl_program
git bisect bad 8417bf528eb155028d56acaa4cbe05eb3536093b
# good: [8a69ae5345045af4642145ad0bcfd1314d4d949e] mesa/compiler: add local_size_variable to shader_info
git bisect good 8a69ae5345045af4642145ad0bcfd1314d4d949e
# good: [31c04e4e229bec4e059779b4034cf597ceeadf97] i965: get LinkedTransformFeedback from gl_transform_feedback_object
git bisect good 31c04e4e229bec4e059779b4034cf597ceeadf97
# bad: [3177eef39277b64af3213603b58ff934b5218e39] mesa: store gl_program in gl_transform_feedback_object rather than gl_shader_program
git bisect bad 3177eef39277b64af3213603b58ff934b5218e39
# bad: [700bc94dcebf4257740483d2ba467b138234fa1a] mesa/glsl: move LinkedTransformFeedback from gl_shader_program to gl_program
git bisect bad 700bc94dcebf4257740483d2ba467b138234fa1a
# first bad commit: [700bc94dcebf4257740483d2ba467b138234fa1a] mesa/glsl: move LinkedTransformFeedback from gl_shader_program to gl_program
Comment 3 Kenneth Graunke 2016-12-30 20:12:12 UTC
Could be more union problems, similar to bug 99229 (though my no means a duplicate).
Comment 4 Kenneth Graunke 2016-12-30 23:48:34 UTC
Turns out it was different breakage.

Should be fixed by:

commit 62a819184141133478cfdcfa76b62d5bb7e14fd5
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Fri Dec 30 15:35:02 2016 -0800

    i965: Avoid NULL pointer dereference when transform feedback is off.
    upload_3dstate_streamout can be called when there's no currently bound
    transform feedback object.  In this case, we get the default object,
    which has a NULL shader (previously gl_shader_program, now gl_program).
    The old code did something sketchy, but which worked:
       const struct gl_transform_feedback_info *linked_xfb_info =
    Here, if shader_program is NULL, this would be a bogus pointer of 0x60.
    But we never actually dereferenced it, so it worked out.
    With Timothy's recent reworks, we actually end up dereferencing
    xfb_obj->program along the way, which crashes since it's NULL.
    The solution is to move this pointer initialization into the "active"
    block, where we know it actually exists and won't be bogus.
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99231
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
    Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>

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.