Porting to AmigaOS4 thread

Ignore Reproc. Not needed anymore.

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.

@walkero

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).

@walkero

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().

@Capehill
Thank you for checking this out.

The Gfx memory leak is about 10MB. This leak disappears when I compile the program without -DLITE_USE_SDL_RENDERER
https://git.walkero.gr/walkero/lite-xl ... s4-1.16.12/os4build.sh#L3

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.

@Capehill
Your gut was right. That function is never executed. And the reason is the atexit() function at
https://git.walkero.gr/walkero/lite-xl ... 4-1.16.12/src/main.c#L124

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.

@walkero

On Linux side you could also try Valgrind, maybe it confirms the issue.

Thank you both for your insights and help. A new version is released at https://git.walkero.gr/walkero/lite-xl/releases/tag/v1.16.12.4 that has this memory fix.

@walkero

Works fine here!!!




BTW no twitch stream yesterday!?!?!? you lazy....

@all

Please help



Line in question is

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?

using namespace std;
doesn't help


The second error (posY) is probably a collateral?

Thanks in advance

@Raziel
https://stackoverflow.com/questions/12 ... nd-is-not-a-member-of-std

The std::round functions are C++11, so you would need to compile with C++11 or a more recent standard enabled.

Are you sure your "-std" options is working?

@jabirulo

I found that stackoverflow entry and read it, yes, but...

...how would i do that apart from using -std=c++11?

@Raziel

gcc version you're using?

https://www.generacodice.com/en/artico ... not+a+member+of+%27std%27
float myRoundFunc(float toRound)
{
return std::ceil(toRound - 0.5);
}

testing with gcc v8:


#g++ round.cpp -athread=native
#a.out
hola
2
#g++ -v
Using built-in specs.
COLLECT_GCC=/Devel/SDK/gcc/bin/g++
COLLECT_LTO_WRAPPER=/Devel/SDK/gcc/bin/../libexec/gcc/ppc-amigaos/8.4.0/lto-wrapper
Target: ppc-amigaos
...
gcc version 8.4.0 (adtools build 8.4.0)
#

@jabirulo

gcc --version
gcc (adtools build 11.1.0) 11.1.0

Hmm, maybe i need to get rid of the "std::" in front of round?
edit: nope

@Raziel

yep, try just "round()" no "std::round()"

or can you try with gcc v8 or v10 ?


Does my "silly" example compile/work for you?

@jabirulo

:-/
Great, it relies on gettext...how could i not see that?

@Raziel

removing "std::" works here.

From the code snippet you've posted here i recognized you're working on a port of Freegemas.

I finished the Port two days ago :)



I just need some more time for QA and Release. But game is working very well so far.

@IamSONIC

OK, i can scrap that then.

How did you fix the gettext and dwarf errors?

@Raziel

gettext:

inter.h - L4

#if defined(__vita__) || defined(WIN32) || defined(__amigaos4__)

no dwarf errors here.