| Summary: | i915 driver crashes if too few vertices are submitted (Mesa 7.10.2) | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Matthias Hopf <mat> |
| Component: | Drivers/DRI/i915 | Assignee: | marius predut <marius.predut> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | CC: | sndirsch |
| Version: | 7.10 | Keywords: | NEEDINFO |
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | crash_too_few_vertices.c | ||
There have been some recent changes in this area on master. Can you reproduce the bug there? As soon as I've got some spare time I'll do it. Expect results next week or so. As this might be related with the bug https://bugs.freedesktop.org/show_bug.cgi?id=47859 I compiled the attachment by calling g++ -lglut -lGL crash_too_few_vertices.c on Debian with i915 driver and libgl1-mesa-dri-dbg 8.0-2 (from experimental) and it leads to an SIGSEGV, Segmentation fault as described before. A patch that fix this was submitted to the mesa mailing list. Fixed by the following patch series. These should get picked to Mesa 11.0.1 and whatever the next 10.6.x release is. commit 25543d8ec506ef32599af6f5e0dd735e01b39909 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Mon Sep 14 11:59:22 2015 -0700 t_dd_dmatmp: Use addition instead of subtraction in loop bounds This is used everywhere else in this file because it avoids problems when count is zero (due to trimming). No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109 Reviewed-by: Brian Paul <brianp@vmware.com> Cc: Marius Predut <marius.predut@intel.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> commit c0b3b2f7603eab210acdb2e654e5411fe912ca34 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Mon Sep 14 11:56:20 2015 -0700 t_dd_dmatmp: Pull out common 'count -= count & 3' code This was missing in the HAVE_TRIANGLES path, and that could cause incorrect rendering. No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38109 Reviewed-by: Brian Paul <brianp@vmware.com> Cc: Marius Predut <marius.predut@intel.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> commit 0d475ee2b989ac1697720ca391913e9158156bdc Author: Ian Romanick <ian.d.romanick@intel.com> Date: Mon Sep 14 11:50:28 2015 -0700 t_dd_dmatmp: Use '& 3' instead of '% 4' everywhere No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> commit fad8d54de7e7f908cb0d06f0b54af8440e689928 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Mon Sep 14 11:46:50 2015 -0700 t_dd_dmatmp: Clean up improper code formatting from previous patch No piglit regressions on i915 (G33) or radeon (Radeon 7500). Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> commit d7bf7969b90f66ee614f2d2225f3a821d5396a89 Author: Ian Romanick <ian.d.romanick@intel.com> Date: Mon Sep 14 11:37:12 2015 -0700 t_dd_dmatmp: Make "count" actually be the count The value passed in count previously was "vertex after the last vertex to be processed." Calling that "count" was misleading and kind of mean. Looking at the code, many functions immediately do "count-start" to get back the true count. That's just silly. If it is better for the loops to be 'for (j = start; j < (start + count); j++)', GCC will do that transformation. NOTE: There is some strange formatting left by this patch. That was done to make it more obvious that the before and after code is equivalent. These will be fixed in the next patch. No piglit regressions on i915 (G33) or radeon (Radeon 7500). v2: Fix a remaining (count-start) in render_quad_strip_verts. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> [v1] Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org> |
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 47767 [details] crash_too_few_vertices.c If too few vertices are submitted in between glBegin()/glEnd() (and probably also for vertex arrays), the stack is overwritten and Mesa crashes without a meaningful stack trace. By single stepping I found the culprit: (gdb) bt #0 intel_render_quads_verts (ctx=0x81ce390, start=0, count=1, flags=55) at ../../../../../src/mesa/tnl_dd/t_dd_dmatmp.h:636 #1 0xb683457a in intel_run_render (ctx=0x81ce390, stage=0x8225468) at intel_render.c:247 #2 0xb691a4c2 in _tnl_run_pipeline (ctx=0x81ce390) at tnl/t_pipeline.c:153 #3 0xb68780eb in intelRunPipeline (ctx=0x81ce390) at intel_tris.c:1075 #4 0xb691ae00 in _tnl_draw_prims (ctx=0x81ce390, arrays=0x8213498, prim=0x8211e6c, nr_prims=1, ib=0x0, min_index=0, max_index=0) at tnl/t_draw.c:518 #5 0xb691b3b1 in _tnl_vbo_draw_prims (ctx=0x81ce390, arrays=0x8213498, prim=0x8211e6c, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index= 0, max_index=0) at tnl/t_draw.c:424 #6 0xb6911d35 in vbo_exec_vtx_flush (exec=0x8211cf8, unmap=1 '\001') at vbo/vbo_exec_draw.c:381 #7 0xb690f827 in vbo_exec_FlushVertices_internal (ctx=0x81ce390, unmap=1 '\001') at vbo/vbo_exec_api.c:911 #8 0xb690fa38 in vbo_exec_FlushVertices (ctx=0x81ce390, flags=1) at vbo/vbo_exec_api.c:945 #9 0xb68b5b09 in _mesa_LoadMatrixf (m=0x8086e80) at main/matrix.c:353 (gdb) n 630 INIT(GL_TRIANGLES); [...] (gdb) n 632 for (j = start; j < count-3; j += 4) { (gdb) p start $11 = 0 (gdb) p count $12 = 1 (gdb) p count-3 $14 = 4294967294 Apparently, count isn't validated before, and it's unsigned. Question remains whether this should be tested in some upper Mesa layer, because probably more drivers are affected by this. Find a glut testcase in the attachment.