Bug 29646

Summary:	baddrawable when resizing a window in gnome-shell/mutter
Product:	Mesa	Reporter:	Alban Browaeys <prahal>
Component:	GLX	Assignee:	mesa-dev
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	medium	CC:	bugs.freedesktop, nalimilan
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	check if the xDrawable is still registered before freeing it backtrace of mutter ignore bad drawable error from dri2 destroy drawable.

Description Alban Browaeys 2010-08-18 07:31:12 UTC

Created attachment 37951 [details] [review]
check if the xDrawable is still registered before freeing it

mutter produces :
Unexpected X error: BadDrawable (invalid Pixmap or Window parameter) serial 14367 error_code 9 request_code 137 minor_code 4)
and abort when resizing a window.

My clue for this patch was that Xserver freed the xDrawable before the client does. DRI2DrawableGone is indeed called with the same id for the drawable.

Attached patch fix that though it needs review. I am too new to x11 lowlevel and glx stuff to be confident it is the proper fix. At least it works.

Comment 1 Alban Browaeys 2010-08-18 07:35:22 UTC

Created attachment 37952 [details]
backtrace of mutter

Also reported in gnome bugzilla : https://bugzilla.gnome.org/show_bug.cgi?id=626556

Comment 2 Alban Browaeys 2010-08-18 07:54:17 UTC

(In reply to comment #1)
> Created an attachment (id=37952) [details]
> backtrace of mutter
> 
> Also reported in gnome bugzilla :
> https://bugzilla.gnome.org/show_bug.cgi?id=626556

(In reply to comment #0)
> Created an attachment (id=37951) [details]
> check if the xDrawable is still registered before freeing it
> 
> mutter produces :
> Unexpected X error: BadDrawable (invalid Pixmap or Window parameter) serial
> 14367 error_code 9 request_code 137 minor_code 4)
> and abort when resizing a window.
> 
> My clue for this patch was that Xserver freed the xDrawable before the client
> does. DRI2DrawableGone is indeed called with the same id for the drawable.
> 
> Attached patch fix that though it needs review. I am too new to x11 lowlevel
> and glx stuff to be confident it is the proper fix. At least it works.

I inverted the condition in the patch. Putting it back the way it should and the issue is back. Any clue welcomed.

Comment 3 Kristian Høgsberg 2010-08-19 07:34:26 UTC

Created attachment 37983 [details] [review]
ignore bad drawable error from dri2 destroy drawable.

Please give this patch a try.

Comment 4 Owen Taylor 2010-09-23 13:18:10 UTC

(In reply to comment #3)
> Created an attachment (id=37983) [details]
> ignore bad drawable error from dri2 destroy drawable.
> 
> Please give this patch a try.

I'm wondering if a client side approach like this can possibly be right. If the sequence:

 XDestroyPixmap()
 glxDestroyPixmap()

Then the sequence:

 XDestroyPixmap()
 [ arbitrary time passes ]
 [ GLX pixmap ID is recycled via client/server negotiation ]
 glxDestroyPixmap()

is also valid. So, I'd think that if glxDestroyPixmap() can follow XDestroyPixmap() the GLX pixmap X ID has to be kept around and not deallocated in the server until glXDestroyPixmp is called (or the client exits)

Comment 5 Michel Dänzer 2010-09-24 00:29:00 UTC

(In reply to comment #4)
> So, I'd think that if glxDestroyPixmap() can follow XDestroyPixmap() the GLX
> pixmap X ID has to be kept around and not deallocated in the server until
> glXDestroyPixmp is called (or the client exits)

That is the case: Pixmaps are reference counted in the X server, and GLXPixmaps take a reference on the backing X pixmaps.

Comment 6 Adam Jackson 2019-09-18 17:14:42 UTC

Ancient bug that bztogl doesn't want to import correctly for whatever reason, closing.

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.