libsdl-org
Memory Leak in SDL_ShowOpenFileDialog with File Selection on Windows
Hello, I encountered an unusual behavior with the
SDL_ShowOpenFileDialog function. Upon opening, the function uses a significant amount of memory. When closing the dialog without selecting a file, it releases most of the allocated memory. However, if a file is selected, it does not fully release the memory after the dialog is closed.
This issue was observed while developing a wrapper for this function in C#. I am not very experienced in C, so I am unable to test this issue directly with raw SDL code. However, from the C# side, it seems that there is just a straightforward call to SDL_ShowOpenFileDialog without any additional allocations. You can build and test my wrapper if you'd like to investigate further.
Steps to Reproduce:
- Initialize SDL.
- Call
SDL_ShowOpenFileDialog, passing a window pointer and a callback, leaving other parameters as null.
Environment:
OS: Windows 10 Pro 22H2 (x64)
No, I wouldn't leave an expected memory leak undocumented, much less one that's in the hundreds of megabytes :)
If the C callback never returns, I expect the file names to never be freed, but that should leak at most a few kilobytes, unless the user selects thousands of files with very long paths. I'll check on my Windows in a while to see if I get any leak.
Could the "issue" be caused by the common dialogs library being loaded at runtime (and it will stay loaded afterwards as well)?
It's possible it comes into play, but that wouldn't explain the quite extreme difference between selecting a file and no file at all...
I've been trying to reproduce this and although I do notice some funny stuff happening in memory, I don't get anything close to a 100Mb memory difference.
@edwardgushchin Can you compile SDL with -DSDL_TESTS=ON passed to CMake, and run <build folder>/tests/testdialog.exe and see what the memory leaks look like there?
@Semphriss I did as you said and got an acceptable result. Further research showed that the leak occurs only in this particular project and only in the situation when a debugger is connected.
I don’t understand why this is so. But the problem, apparently, is not in SDL or the wrapper.
I think what you're seeing is comdlg32 caching data such that later dialogs go faster.
Using the "Open..." dialog of notepad.exe gives a similar memory profile.
That said, windows_ShowFileDialog loads comdlg32.dll, but never frees it.
