Bug 70599

Summary:	[SNB/IVB/HSW Bisected]Piglit glx/GLX_ARB_create_context/current_with_no_framebuffer segfault
Product:	Mesa	Reporter:	lu hua <huax.lu>
Component:	Mesa core	Assignee:	mesa-dev
Status:	VERIFIED FIXED	QA Contact:	Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity:	major
Priority:	high	CC:	idr, kai
Version:	unspecified
Hardware:	All
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Full GDB backtrace with radeonsi

Description lu hua 2013-10-18 07:46:17 UTC

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

Comment 1 Kai 2013-10-27 15:38:39 UTC

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".

Comment 2 Tapani Pälli 2014-09-11 11:20:23 UTC

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.

Comment 3 lu hua 2014-09-12 05:25:05 UTC

(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.