System Environment: -------------------------- Platform: Sandybridge/Ivybridge/Haswell Libdrm: (master)2.4.47 Mesa: (9.2)bf9be81b47270dd7ee42b5fe7e8fcf37a7238bee Xserver: (server-1.14-branch)xorg-server-1.14.3 Xf86_video_intel:(master)2.99.904-32-gec0866e86d365ae3fd9790b1b263d49fc4981220 Cairo: (master)6f05ecf488314e4b0c6c6b0110963c449bebe7d7 Libva: (master)73a11b3e249da35ede92560eb089239252721351 Libva_intel_driver:(master)01b39f7ef75c028a99a02e98af6ec9ca2a9c6773 Kernel: (drm-intel-fixes) cd66407810869709e0d6764409137d48c6812cfc Bug detailed description: ----------------------------- It segfault on Sandybridge/Ivybridge/Haswell with mesa master and 9.2 branch. Bisect shows:e166a58c43e92f10f03b32747bff44708096f898 is the first bad commit. commit e166a58c43e92f10f03b32747bff44708096f898 Author: Adam Jackson <ajax@redhat.com> Date: Fri Oct 4 09:25:51 2013 -0400 glx: Generate fewer errors in MakeContextCurrent For a few reasons. 1: In the (current) common case, these conditionals are never true. All we're doing by checking them is slowing down MakeCurrent. The server does these checks already anyway. 2: GLX >= 3.0 contexts may legally be made current without a bound framebuffer. This does not fix piglit/glx-create-context-current-no-framebuffer, but is a prerequisite for fixing it. Cc: "9.1 9.2" <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com> Signed-off-by: Adam Jackson <ajax@redhat.com> output: Segmentation fault (core dumped) (gdb) bt #0 XQueryExtension (dpy=dpy@entry=0xffffffff, name=name@entry=0x7ffff7cb14b8 <dri2ExtensionName> "DRI2", major_opcode=major_opcode@entry=0x7fffffffde64, first_event=first_event@entry=0x7fffffffde68, first_error=first_error@entry=0x7fffffffde6c) at QuExt.c:43 #1 0x00007ffff74b8c15 in XInitExtension (dpy=dpy@entry=0xffffffff, name=name@entry=0x7ffff7cb14b8 <dri2ExtensionName> "DRI2") at InitExt.c:47 #2 0x00007ffff5e5007b in XextAddDisplay (extinfo=0x603330, dpy=dpy@entry=0xffffffff, ext_name=ext_name@entry=0x7ffff7cb14b8 <dri2ExtensionName> "DRI2", hooks=hooks@entry=0x7ffff7cb14c0 <dri2ExtensionHooks>, nevents=nevents@entry=0, data=data@entry=0x0) at extutil.c:110 #3 0x00007ffff7a7a524 in DRI2FindDisplay (dpy=dpy@entry=0xffffffff) at dri2.c:81 #4 0x00007ffff7a7b0c7 in DRI2GetBuffersWithFormat (dpy=0xffffffff, drawable=9176480, width=width@entry=0x8bf898, height=height@entry=0x8bf89c, attachments=0x7fffffffdfe0, count=0, outCount=outCount@entry=0x7fffffffe00c) at dri2.c:465 #5 0x00007ffff7a7893c in dri2GetBuffersWithFormat (driDrawable=<optimized out>, width=0x8bf898, height=0x8bf89c, attachments=<optimized out>, count=<optimized out>, out_count=0x7fffffffe00c, loaderPrivate=0x33ee3b97d8 <main_arena+88>) at dri2_glx.c:905 #6 0x00007ffff493758f in intel_query_dri2_buffers (buffer_count=0x7fffffffe00c, buffers=<synthetic pointer>, drawable=0x8bf870, brw=0x61e320) at intel_context.c:841 #7 intel_update_renderbuffers (context=context@entry=0x619810, drawable=drawable@entry=0x8bf870) at intel_context.c:196 #8 0x00007ffff49378c2 in intel_prepare_render (brw=brw@entry=0x61e320) at intel_context.c:249 #9 0x00007ffff4938828 in intelMakeCurrent (driContextPriv=0x619810, driDrawPriv=0x8bf870, driReadPriv=0x8bf870) at intel_context.c:764 #10 0x00007ffff49cfc2f in driBindContext (pcp=<optimized out>, pdp=<optimized out>, prp=<optimized out>) at dri_util.c:382 #11 0x00007ffff7a7a0df in dri2_bind_context (context=0x6109c0, old=<optimized out>, draw=<optimized out>, read=<optimized out>) at dri2_glx.c:172 #12 0x00007ffff7a4e95a in MakeContextCurrent (dpy=0x602010, draw=0, read=0, gc_user=0x6109c0) at glxcurrent.c:259 #13 0x0000000000401285 in main (argc=3, argv=0x7fffffffe268) at /GFX/Test/Piglit/piglit/tests/spec/glx_arb_create_context/current-no-framebuffer.c:77 Reproduce steps: ---------------------------- 1. xinit& 2. bin/glx-create-context-current-no-framebuffer -auto -fbo
Created attachment 88180 [details] Full GDB backtrace with radeonsi I can confirm this bug with radeonsi, the graphics stack used is: GPU: "PITCAIRN" (ChipID = 0x6819) Linux: 3.11.6 libdrm: 2.4.47 LLVM: SVN:trunk/r193475 libclc: Git:master/4c18120c1a Mesa: Git:master/64c081e8b7 GLAMOR: Git:master/ba209eeef2 DDX: Git:master/f1dc677e79 This bug should probably be assigned to "Mesa core".
The commit mentioned in the bug description has been reverted from Mesa 9.2 tree, the test still fails on 9.2 but does not segfault. Mesa versions with the test: - 9.2 fail - 10.0 segfault - 10.1 pass - 10.2 pass - 10.3 pass - 10.4-dev (6816d85) pass For gallium it has been fixed to pass by commit db8b6fb, not sure what fixes it for others. As it now passes on master, I'll resolved this as fixed.
(In reply to comment #2) > The commit mentioned in the bug description has been reverted from Mesa 9.2 > tree, the test still fails on 9.2 but does not segfault. > > Mesa versions with the test: > > - 9.2 fail > - 10.0 segfault > - 10.1 pass > - 10.2 pass > - 10.3 pass > - 10.4-dev (6816d85) pass > > For gallium it has been fixed to pass by commit db8b6fb, not sure what fixes > it for others. As it now passes on master, I'll resolved this as fixed. Test on mesa master branch and 10.3 branch. The segfault goes away, but it's fail(Bug 79629). Close it. output: PIGLIT: {"result": "fail" }
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.