We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4819 - Attempting to create an OpenGL ES context with unachievable MSAA parameters under X11 dooms the program
Summary: Attempting to create an OpenGL ES context with unachievable MSAA parameters u...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 2.0.9
Hardware: x86_64 Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-08 08:04 UTC by Solra Bizna
Modified: 2019-11-17 06:36 UTC (History)
0 users

See Also:

Attachments
Simple test program that demonstrates the bug (831 bytes, text/x-csrc)
2019-10-08 08:04 UTC, Solra Bizna 		Details
Patch that eliminates redundant calls to XDestroyWindow (650 bytes, patch)
2019-10-09 20:11 UTC, Solra Bizna 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Solra Bizna 2019-10-08 08:04:54 UTC 
Created attachment 3979 [details]
Simple test program that demonstrates the bug

I have written a program that, in the event that the user requests more MSAA samples than their hardware supports, attempts to gracefully fall back to the best MSAA available. This code works with my conventional OpenGL renderer, but if I change nothing about the code except to make it request an OpenGL ES profile instead, Xlib kills the program with an error that looks like:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  4 (X_DestroyWindow)
  Resource id in failed request:  0x5c00008
  Serial number of failed request:  188
  Current serial number in output stream:  193

To trigger the bug, attempt to create a window with the SDL_WINDOW_OPENGL flag, with SDL_GL_CONTEXT_PROFILE_MASK set to SDL_GL_CONTEXT_PROFILE_ES, and with SDL_GL_MULTISAMPLESAMPLES set to any unsupported value. SDL_CreateWindow properly returns NULL, but at this point the program is already doomed. Xlib will shortly terminate the program with an error. Calling SDL_CreateWindow again will immediately trigger this termination.

I have attached a skeletal program that reproduces this bug for me. Replacing SDL_GL_CONTEXT_PROFILE_ES with SDL_GL_CONTEXT_PROFILE_COMPATIBILITY avoids the bug (but, obviously, doesn't create an OpenGL ES context).

I suspect that this bug stems from X_DestroyWindow getting called twice on the same window, but I don't have time to investigate it myself at the moment.
Comment 1 Solra Bizna 2019-10-09 20:11:05 UTC 
Created attachment 3980 [details]
Patch that eliminates redundant calls to XDestroyWindow
Comment 2 Solra Bizna 2019-10-09 20:11:23 UTC 
I found the time to investigate.

As I suspected, the problem was with XDestroyWindow being called twice on the same window. The X11_CreateWindow function in src/video/x11/SDL_x11window.c calls SetupWindowData. If initialization fails after that point, XDestroyWindow gets called on the window by a subsequent call to X11_DestroyWindow. But, later in the same function, iff a GLES context is requested and initializing it fails, X11_XDestroyWindow (which wraps XDestroyWindow) is manually called. Shortly after, the intended call to X11_DestroyWindow occurs, which attempts to destroy the same window again. Boom.

(The above confusing summary involves three separate, similarly-named functions: XDestroyWindow, X11_DestroyWindow, X11_XDestroyWindow)

I have attached a simple patch that removes the redundant X11_XDestroyWindow calls. I've tested that XDestroyWindow still gets called for the windows in question, and that it only gets called once.
Comment 3 Solra Bizna 2019-10-19 20:56:54 UTC 
It occurs to me that I left out two important details: My investigation showed that the bug affects 2.0.10 as well, and my patch seems to fix the bug.
Comment 4 Sam Lantinga 2019-11-17 06:36:08 UTC 
Looks good, thanks!
https://hg.libsdl.org/SDL/rev/6e17e1a6cf2e