Mon, 14 Aug 2017 20:25:53 -0700Added missing files from the previous commit
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Aug 2017 20:25:53 -0700] rev 11297
Added missing files from the previous commit

Mon, 14 Aug 2017 20:22:19 -0700Fixed bug 2330 - Debian bug report: SDL2 X11 driver buffer overflow with large X11 file descriptor
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Aug 2017 20:22:19 -0700] rev 11296
Fixed bug 2330 - Debian bug report: SDL2 X11 driver buffer overflow with large X11 file descriptor

manuel.montezelo

Original bug report (note that it was against 2.0.0, it might have been fixed in between): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733015

--------------------------------------------------------
Package: libsdl2-2.0-0
Version: 2.0.0+dfsg1-3
Severity: normal
Tags: patch

I have occasional crashes here caused by the X11 backend of SDL2. It seems to
be caused by the X11_Pending function trying to add a high number (> 1024)
file descriptor to a fd_set before doing a select on it to avoid busy waiting
on X11 events. This causes a buffer overflow because the file descriptor is
larger (or equal) than the limit FD_SETSIZE.

Attached is a possible workaround patch.

Please also keep in mind that fd_set are also used in following files which
may have similar problems.

src/audio/bsd/SDL_bsdaudio.c
src/audio/paudio/SDL_paudio.c
src/audio/qsa/SDL_qsa_audio.c
src/audio/sun/SDL_sunaudio.c
src/joystick/linux/SDL_sysjoystick.c


--------------------------------------------------------

On Tuesday 24 December 2013 00:43:13 Sven Eckelmann wrote:
> I have occasional crashes here caused by the X11 backend of SDL2. It seems
> to be caused by the X11_Pending function trying to add a high number (>
> 1024) file descriptor to a fd_set before doing a select on it to avoid busy
> waiting on X11 events. This causes a buffer overflow because the file
> descriptor is larger (or equal) than the limit FD_SETSIZE.


I personally experienced this problem while hacking on the python bindings
package for SDL2 [1] (while doing make runtest). But it easier to reproduce in
a smaller, synthetic testcase.

Mon, 14 Aug 2017 20:07:30 -0700Fixed compiler warnings
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Aug 2017 20:07:30 -0700] rev 11295
Fixed compiler warnings

Mon, 14 Aug 2017 16:34:54 -0700Fixed bug 2344 - CHECK_WINDOW_MAGIC should include __FILE__ and __LINE__
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Aug 2017 16:34:54 -0700] rev 11294
Fixed bug 2344 - CHECK_WINDOW_MAGIC should include __FILE__ and __LINE__

Martin Gerhardy

just for easier debugging issues in the own code...

SDL_CreateRenderer should maybe also use this macro

Ryan C. Gordon

I'll go one better: it should have an SDL_assert().

Mon, 14 Aug 2017 16:09:44 -0700Fixed Windows build due to an implicit memcpy generated by the optimizer
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Aug 2017 16:09:44 -0700] rev 11293
Fixed Windows build due to an implicit memcpy generated by the optimizer

Mon, 14 Aug 2017 14:14:45 -0700Fixed bug 3753 - Android : load methodID during initialization
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Aug 2017 14:14:45 -0700] rev 11292
Fixed bug 3753 - Android : load methodID during initialization

Sylvain

Small patch to load some java methodID at start-up (and avoid a potential crash at run-time).

Mon, 14 Aug 2017 14:10:48 -0700Fixed bug 2360 - Wrong -rpath setting includes DESTDIR rather that only the libdir
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Aug 2017 14:10:48 -0700] rev 11291
Fixed bug 2360 - Wrong -rpath setting includes DESTDIR rather that only the libdir

Marcus von Appen

The LT_LDFLAGS in Makefile.in contain the $(DESTDIR) in -rpath, which instructs libtool to take a wrong path into account for linking.

The issue arises, if DESTDIR is passed at build time and installation time.
-rpath only should use $(libdir) for both SDL 1.2 and SDL 2.x.

Mon, 14 Aug 2017 13:48:13 -0700Fixed bug 2418 - Structure SDL_gestureTouch leaking
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Aug 2017 13:48:13 -0700] rev 11290
Fixed bug 2418 - Structure SDL_gestureTouch leaking

Leonardo

Structure SDL_gestureTouch gets reallocated for every new added gesture but its never freed.

Proposed patch add the function SDL_GestureQuit() that takes care of doing that and gets called when TouchQuit is called.

Gabriel Jacobo

Thanks for the patch. I think it needs a bit of extra work though, looking at the code in SDL_gesture.c , I see that SDL_numGestureTouches only goes up, I think the right fix here involves adding SDL_GestureDelTouch (hooked into SDL_DelTouch) as well as SDL_GestureQuit (as you posted in your patch).

Mon, 14 Aug 2017 13:37:14 -0700Fixed bug 2441 - SDL_DuplicateSurface
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Aug 2017 13:37:14 -0700] rev 11289
Fixed bug 2441 - SDL_DuplicateSurface


Rainer Deyke

I've written a small patch that adds a small SDL_DuplicateSurface function to SDL. I've written the function as part of a larger (as yet unfinished) patch, but I think this function is useful enough that it merits inclusion in SDL on its own.

Mon, 14 Aug 2017 10:28:47 -0700Fixed bug 2500 - X11: SDL tries (and fails) to hide foreign windows
Sam Lantinga <slouken@libsdl.org> [Mon, 14 Aug 2017 10:28:47 -0700] rev 11288
Fixed bug 2500 - X11: SDL tries (and fails) to hide foreign windows

Alvin

I'm interested in this bug as well. I have experienced it when trying to embed an SDL_Window into a FLTK application. To do this, I create a FLTK window (window inside a window - think video player) and then use SDL_CreateWindowFrom() on the inner most window's Xlib Window*. After which, I create a renderer.

In my situation I am using the FLTK GUI toolkit.

What I have experienced is that the SDL_CreateRender() will recreate the window in order to properly setup OpenGL capability. As part of this process, the window is hidden and a call is executed that waits indefinitely for an acknowledgement that the window was indeed unmapped. This is where my program hangs.

Please correct me if I am wrong, but should SDL2 not make Xlib calls that effect the Xlib Window in this situation (e.g. When SDL_CreateWindowFrom() is used)? The toolkit being used typically assumes responsibility and, I presume, tracks all Xlib Windows it creates.

On line src/video/SDL_video.c:1372 the comment associated with setting SDL_WINDOW_FOREIGN reads:

/* Can't destroy and re-create foreign windows, hrm */

Since I do not know the reason for hiding the window in the first place, the attached patch simply does not wait for a response when X11_XWithdrawWindow() and X11_XMapRaised() are issued by X11_HideWindow() and X11_ShowWindow(), respectively. I presume that the GUI toolkit (GTK, FLTK, etc.) has or will consume the acknowledging event as it is managing the Xlib Window (or it thinks it is).

I have tested the patch against hg d09d4b578e77 and I have successfully tested:
* Embedding the SDL_Window inside a FLTK application.
* Calling SDL_SetWindowSize() when FLTK resizes the window (e.g. dragging cursor on the edge of the window).
* Filling the renderer's default target blue and drawing a red fill square at the centre (exciting, I know!)
* Calling SDL_Quit() when the application terminates

I do not receive any Xlib erorr messages (BadWindow, etc.) in any of those situations.