- October 2020
- June 2020
- May 2020
- October 2019
- June 2019
- September 2018
- May 2018
- December 2017
- April 2017
- June 2016
- February 2016
- November 2015
- January 2015
- August 2014
- July 2014
- May 2014
- March 2014
- February 2014
- January 2014
- November 2013
- August 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- December 2012
- November 2012
- September 2012
- June 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- September 2011
- July 2011
- June 2011
- May 2011
- March 2011
- January 2011
- October 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- September 2009
- July 2009
- June 2009
- May 2009
- March 2009
- September 2008
- April 2008
- December 2007
- June 2007
- June 2005
- September 2004
- May 2002
- October 2001
- August 2001
2009-06-20: Memory leak in SDL
DOSBox makes use of the SDL library with a few slight modifications for performance on Windows. This exposes a memory leak in SDL 1.2.x. I have filed a bug report and fix with the SDL people, but since this code path is not used under normal circumstances, only in DOSBox, they are not likely to incorporate it any time soon.
At the suggestion of DOSBox dev c2woody (aka wd) I checked into this. When a program calls SDL_SetVideoMode, the DirectDraw backend in /src/video/windx5/SDL_dx5video.c, function DX5_SetVideoMode allocates a block of memory the size of the frame buffer. It stores this in the pixels member of the surface structure. Unfortunately, the function DX5_LockHWSurface assigns a pointer to the DirectDraw surface to this same member without freeing the original memory block first. That is a memory leak. DOSBox sometimes calls SDL_SetVideoMode in rapid succession, depending on what the programs running inside it do. The Magic Circle is an intro that can leak hundreds of megabytes when run in DOSBox, especially in the final section.
My fix adds an extra member variable to an internal structure that is not exposed to programs using the SDL api and stores the pointer to the buffer in there on the first call to DX5_LockHWSurface. When closing the video subsystem or switching to another video mode, this pointer is then probably released. I could have chosen not to allocate the memory in the first place or release the buffer the moment the pointer was overwritten, but this is more compatible. Although it is bad programming practice, it is actually possible that a program makes a copy of the pointer before it gets overwritten and uses it for its own purposes. Such a program would crash if the observable behaviour changed. In the fix, the observable behaviour is retained at least until the next call to SDL_SetVideoMode.
As this fix is not likely to make it into mainstream SDL any time soon, I'm posting the patch and an updated DLL here:
Comments
No comments, yet...
Post a comment