<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Memory corruption (crash) in draw/draw_pt_fetch_shade_pipeline_llvm.c:435" href="https://bugs.freedesktop.org/show_bug.cgi?id=72926#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Memory corruption (crash) in draw/draw_pt_fetch_shade_pipeline_llvm.c:435" href="https://bugs.freedesktop.org/show_bug.cgi?id=72926">bug 72926</a> from <a class="email" href="mailto:lekensteyn@gmail.com" title="Peter Wu <lekensteyn@gmail.com>"> Peter Wu</a> <pre>Created <a href="attachment.cgi?id=92081" name="attach_92081" title="Small test program (robot.c)">attachment 92081</a> <a href="attachment.cgi?id=92081&action=edit" title="Small test program (robot.c)">[details]</a> Small test program (robot.c) Here is a small test program that crashes with Mesa 10.0 (and master). On startup, it immediately crashes. A heap-buffer-overflow according to ASAN. Some notes: - It has something to do with anti-aliasing (with GL_LINE_SMOOTH disabled, it runs fine). - The problem is probably related to negative vertices and clipping. If the triangle vertex (-10,100) is changed to (-1,100), it still crashes but (0,100) is fine. - It is an combination of vertices, if I remove two vertices for GL_LINES, then it won't crash. Another hint is the following assertion failure when replacing GL_LINES by GL_POINTS: lp_setup_vbuf.c:112:lp_setup_unmap_vertices: Assertion `setup->vertex_buffer_size >= (max_index+1) * setup->vertex_size' failed. Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007fffefc004a5 in _debug_assert_fail (expr=expr@entry=0x7ffff01f9be0 "setup->vertex_buffer_size >= (max_index+1) * setup->vertex_size", file=file@entry=0x7ffff01f9ba0 "lp_setup_vbuf.c", line=line@entry=112, function=function@entry=0x7ffff01f9d20 <__func__.15180> "lp_setup_unmap_vertices") at util/u_debug.c:278 278 os_abort(); #0 0x00007fffefc004a5 in _debug_assert_fail (expr=expr@entry=0x7ffff01f9be0 "setup->vertex_buffer_size >= (max_index+1) * setup->vertex_size", file=file@entry=0x7ffff01f9ba0 "lp_setup_vbuf.c", line=line@entry=112, function=function@entry=0x7ffff01f9d20 <__func__.15180> "lp_setup_unmap_vertices") at util/u_debug.c:278 #1 0x00007fffeff5be20 in lp_setup_unmap_vertices (vbr=0x60740000a100, min_index=<optimized out>, max_index=<optimized out>) at lp_setup_vbuf.c:112 #2 0x00007fffefb10aeb in vbuf_flush_vertices (vbuf=vbuf@entry=0x601e00009820) at draw/draw_pipe_vbuf.c:323 #3 0x00007fffefb112a9 in vbuf_flush (stage=0x601e00009820, flags=4) at draw/draw_pipe_vbuf.c:392 #4 0x00007fffefaf1ab1 in aaline_flush (stage=0x60360000e4c0, flags=4) at draw/draw_pipe_aaline.c:734 #5 0x00007fffefafe27a in clip_flush (stage=0x602a0001f660, flags=4) at draw/draw_pipe_clip.c:796 #6 0x00007fffefaeb064 in draw_pipeline_flush (draw=draw@entry=0x60680001b100, flags=flags@entry=4) at draw/draw_pipe.c:349 #7 0x00007fffefad26a8 in draw_do_flush (draw=draw@entry=0x60680001b100, flags=flags@entry=4) at draw/draw_context.c:741 #8 0x00007fffefad0571 in draw_flush (draw=draw@entry=0x60680001b100) at draw/draw_context.c:234 #9 0x00007fffeff0da0a in llvmpipe_draw_vbo (pipe=0x606e0001c300, info=0x7fffffffdf10) at lp_draw_arrays.c:155 #10 0x00007fffefacc1e8 in cso_draw_vbo (cso=0x60640001a500, info=info@entry=0x7fffffffdf10) at cso_cache/cso_context.c:1400 #11 0x00007fffef7ed6bb in st_draw_vbo (ctx=<optimized out>, prims=<optimized out>, nr_prims=<optimized out>, ib=<optimized out>, index_bounds_valid=<optimized out>, min_index=<optimized out>, max_index=<optimized out>, tfb_vertcount=<optimized out>, indirect=<optimized out>) at state_tracker/st_draw.c:290 #12 0x00007fffef72f418 in vbo_exec_vtx_flush (exec=exec@entry=0x608800012e48, keepUnmapped=keepUnmapped@entry=1 '\001') at vbo/vbo_exec_draw.c:399 #13 0x00007fffef71c8bc in vbo_exec_FlushVertices_internal (exec=exec@entry=0x608800012e48, unmap=unmap@entry=1 '\001') at vbo/vbo_exec_api.c:555 #14 0x00007fffef72151d in vbo_exec_FlushVertices (ctx=0x7fffe9eb1800, flags=1) at vbo/vbo_exec_api.c:1164 #15 0x00007fffef3ecdc6 in _mesa_flush (ctx=ctx@entry=0x7fffe9eb1800) at main/context.c:1666 #16 0x00007fffef3ed051 in _mesa_Flush () at main/context.c:1701 #17 0x00007ffff4bf1677 in glFlush () at ../../../src/mapi/glapi/glapi_mapi_tmp.h:2968 #18 0x0000000000400ef8 in display () at robot.c:29 #19 0x00007ffff48b4ac4 in ?? () from /usr/lib/libglut.so.3 #20 0x00007ffff48b8329 in fgEnumWindows () from /usr/lib/libglut.so.3 #21 0x00007ffff48b507d in glutMainLoopEvent () from /usr/lib/libglut.so.3 #22 0x00007ffff48b58e5 in glutMainLoop () from /usr/lib/libglut.so.3 #23 0x0000000000401035 in main (argc=1, argv=0x7fffffffe468) at robot.c:57</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>