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 3976 - [PATCH] SDL drivers may leak driverdata memory due to ignoring return value of SDL_AddDisplayMode
Summary: [PATCH] SDL drivers may leak driverdata memory due to ignoring return value o...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.1
Hardware: All All
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-21 18:58 UTC by C Snover
Modified: 2017-11-22 05:31 UTC (History)
0 users

See Also:

Attachments
Fix memory leak on macOS (531 bytes, patch)
2017-11-21 18:58 UTC, C Snover 		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 C Snover 2017-11-21 18:58:48 UTC 
Created attachment 3097 [details]
Fix memory leak on macOS

SDL_AddDisplayMode returns an SDL_bool corresponding to whether or not the given display mode was added or not. It will return SDL_FALSE if a matching display mode already exists in the display’s list of display modes, which causes ownership of the mode driverdata to remain with the caller. Some video drivers ignore the return value of SDL_AddDisplayMode, so leak the driverdata memory when SDL_AddDisplayMode returns SDL_FALSE.

I only have access to macOS, so the attached patch is just for the cocoa driver, but it appears this problem exists for the same GetDisplayModes operation in these video drivers:

SDL_bmodes.cc
SDL_DirectFB_modes.c
SDL_kmsdrmvideo.c
SDL_rpivideo.c
SDL_vivantevideo.c

Additionally, these drivers also don’t always check the return value of SDL_AddDisplayMode, so might leak the same memory in other situations:

SDL_mirvideo.c
SDL_waylandvideo.c
SDL_winrtvideo.cpp

Regards,
Comment 1 Sam Lantinga 2017-11-22 05:31:28 UTC 
I reviewed all the calls, and this was the only one that had modedata that wasn't being freed.
https://hg.libsdl.org/SDL/rev/53049fd16008

Thanks!