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.
Created attachment 37952 [details] backtrace of mutter Also reported in gnome bugzilla : https://bugzilla.gnome.org/show_bug.cgi?id=626556
(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.
Created attachment 37983 [details] [review] ignore bad drawable error from dri2 destroy drawable. Please give this patch a try.
(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)
(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.
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.