Bug 33324

Summary: [bisected] pilgit glx/glx-make-glxdrawable-current regressed
Product: xorg Reporter: fangxun <xunx.fang>
Component: Driver/intelAssignee: Julien Cristau <jcristau>
Status: VERIFIED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high CC: jcristau, keithp
Version: git   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
proposed patch
none
fix request length check for CreateGLXPbufferSGIX
none
work around wrong request lengths from mesa none

Description fangxun 2011-01-21 00:25:53 UTC
System Environment:
--------------------------
Arch:           x86_64
Platform:       piketon 
Libdrm:		(master)2.4.23-6-g550fe2ca3b29ad2191eab4fdfbed9ed21e25492d
Mesa:		(master)e8c7d7598fb48237508f566204c71ba8f74d544f
Xserver:  (master)xorg-server-1.9.99.901-118-gc6aa4755ec355101a62bef86dbb090262fe806f6
Xf86_video_intel: (master)2.14.0-10-g4c4ad555564a80311df1a4b762eb1e119c6d95fb
Kernel:	(drm-intel-next) fe4402931e43e81a4129eba41d05cf8907603af5


Bug detailed description:
-------------------------
The regression happens on all platforms. Bisect shows  361128389e5cb0101cbd091ff8de77cf34608f6c is the first bad commit.
commit 361128389e5cb0101cbd091ff8de77cf34608f6c
Merge: 65ceaad d9225b9
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Jan 18 15:18:08 2011 -0800

    Merge remote branch 'jcristau/for-keith'
Comment 1 Julien Cristau 2011-01-21 14:32:36 UTC
On Fri, Jan 21, 2011 at 00:25:54 -0800, bugzilla-daemon@freedesktop.org wrote:

> Bug detailed description:
> -------------------------
> The regression happens on all platforms. Bisect shows 
> 361128389e5cb0101cbd091ff8de77cf34608f6c is the first bad commit.
> commit 361128389e5cb0101cbd091ff8de77cf34608f6c
> Merge: 65ceaad d9225b9
> Author: Keith Packard <keithp@keithp.com>
> Date:   Tue Jan 18 15:18:08 2011 -0800
> 
>     Merge remote branch 'jcristau/for-keith'
> 
Does this mean d9225b9602c85603ae616a7381c784f5cf5e811c is ok, and
361128389e5cb0101cbd091ff8de77cf34608f6c (the merge commit) isn't?  That
sounds weird...
Comment 2 Julien Cristau 2011-01-23 04:16:51 UTC
I'm getting:

X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  32 (X_GLXDestroyWindow)
  Serial number of failed request:  38
  Current serial number in output stream:  39

That looks like a mesa bug.  src/glx/glx_pbuffer.c::DestroyDrawable (called by glXDestroyWindow) has GetReqExtra(GLXDestroyPbuffer, 4, req);, which sets the request length to 3 instead of 2, for some reason.  The extra 4 bytes don't seem needed by either glXDestroyPixmap or glXDestroyWindow.  Both requests should be 8 bytes, not 12.
Comment 3 Julien Cristau 2011-01-23 04:39:40 UTC
Created attachment 42332 [details] [review]
proposed patch

This fixes it for me.
Comment 4 Julien Cristau 2011-01-23 08:30:37 UTC
Created attachment 42338 [details] [review]
fix request length check for CreateGLXPbufferSGIX

I found a couple more similar bugs in mesa, and one in my xserver patch.
Comment 5 Julien Cristau 2011-01-23 08:31:27 UTC
Created attachment 42339 [details] [review]
work around wrong request lengths from mesa
Comment 6 fangxun 2011-01-25 21:20:11 UTC
Works fine with fixed patch in xserver. BTW, without the fixed patch, it also works fine after updating mesa to 02d7d9ec363c7955105497c518296630cf2b638a.
Comment 7 zhao jian 2011-01-29 00:42:04 UTC
It now works well with newest code on master. 
Tested with: 
Libdrm:		(master)2.4.23-6-g550fe2ca3b29ad2191eab4fdfbed9ed21e25492d
Mesa:		(master)d3df641f0aba99b0b65ecd4d9b06798bca090a29
Xserver:		(master)xorg-server-1.9.99.901-165-gbe3be7580b6f6fd2f7fa4d4abfe5e1ab19470223
Xf86_video_intel: (master)2.14.0-13-gc6dc27562abbc8ca9e873ad502ca49ae010461d2
Cairo:		(master)a8e8d2aba811487dbb5b682c4f55065008e7ebbd
Kernel:	(drm-intel-next) 1a3665c81df32b23c38d4ba8a74761551d5673b1

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.