Is there a way on an SDL application to find were exactly a Gfx memory leak is coming from? I believe it has to do with the SDL part of the app, since it is on Gfx memory, but feel free to correct me if I am wrong.
Do you know how much is leaked and under what conditions? I don't think SDL itself is allocating video memory without user requesting it (like creating some surface or texture).
I had a chance to try LiteXL and after quit it seemed that some megabytes of VRAM were lost - did you mean this? Could you verify using printf that application is truly freeing the texture and renderer resources by calling renwin_free(), https://git.walkero.gr/walkero/lite-xl ... 6.12/src/renwindow.c#L114 ?
Just asking since there was some atexit() path which does only SDL_Quit().
So, as I understand it, the code that is used based on this definition is leaking that amount of memory. The SDL_Quit() was added by me while I was trying to find a possible fix for it. The original source code doesn't have it.
I will try what you said about calling renwin_free() and let you know.
This function executes only the SDL_Quit() on application exit. While this is there, no command after https://git.walkero.gr/walkero/lite-xl ... 4-1.16.12/src/main.c#L217 is executed. So, what I did to be sure about it, is that I created a new method that calls all those methods and the SDL_Quit, and the Gfx memory leak is gone.
I will test on my linux system if that's the exact situation as well, and if this is the case, I will file a bug report, because I check their latest code and this is exactly the same. Also, I will create a new release with this issue fixed.
Thank you so much for the hint. This thing troubled me so many days, and I didn't thought to check if this method actually was executed.
@walkero Not exactly about your problem, but just as remind: With SDL code ported from another system it's quite often they forget to make clean exits. That happens because garbage collectors do it for them, so for example, the same code on win32 will leak nothing while code still bad and will leak on oses where no garbage collector present (like our one)
For example, when OpenGL is used from SDL code, they (coders from other oses) often do just SDL_Quit() and forget to clean gfx / close OpenGL contexts / etc. And that really common problem.
c++ -Wall -Wextra -pedantic -g `sdl2-config --cflags --static-libs` -std=c++11 -ISDK:local/common/include/libxml2 -O -c -o StateMainMenu.o StateMainMenu.cpp
StateMainMenu.cpp: In member function 'virtual void StateMainMenu::draw()':
StateMainMenu.cpp:116:33: error: 'round' is not a member of 'std'; did you mean 'round'?
116 | int posX = std::round(800 / 2 - mMenuRenderedTexts[i].getWidth() / 2),
| ^~~~~
In file included from /Development/Coding/SDK/gcc/include/c++/11.1.0/cmath:45,
from /Development/Coding/SDK/gcc/include/c++/11.1.0/math.h:36,
from /SDK/local/newlib/include/SDL2/SDL_stdinc.h:90,
from /SDK/local/newlib/include/SDL2/SDL_main.h:25,
from /SDK/local/newlib/include/SDL2/SDL.h:32,
from State.h:5,
from StateMainMenu.h:4,
from StateMainMenu.cpp:3:
/SDK/newlib/include/math.h:218:15: note: 'round' declared here
218 | extern double round _PARAMS((double));
| ^~~~~
StateMainMenu.cpp:120:42: error: 'posY' was not declared in this scope; did you mean 'posX'?
120 | mMenuRenderedTexts[i].draw(posX, posY, 3);
| ^~~~
| posX
gmake: *** [StateMainMenu.o] Error 1
Line in question is
// Calculate the horizontal and vertical positions
int posX = std::round(800 / 2 - mMenuRenderedTexts[i].getWidth() / 2),
posY = mMenuYStart + i * mMenuYGap;
What is it trying to tell me? "round" is not usable, why not use "round"??? Are you kidding me? It obviously found it in math.h, but refuses to use it? Why?