Some quick testing shows that both the old and new version of the Windows-only font loader leaks memory at a frantic pace. The investigation continues...
Make this change to the start of _LOADFONT and see if the memory leak continues to occur for you:
int32 func__loadfont(qbs *f,int32 size,qbs *requirements,int32 passed){
//f=_LOADFONT(ttf_filename$,height[,"bold,italic,underline,monospace,dontblend,unicode"])
if (new_error) return NULL;
static qbs *s1=qbs_new(0,0);
static qbs *req=qbs_new(0,0);
static qbs *s3=qbs_new(0,0);
s1 = qbs_new_txt("");
req = qbs_new_txt("");
s3 = qbs_new_txt("");Idea here is to make s1,req,s3 STATIC variables so we only initialize them once with qbs_new(0,0), but then we reset them to being null strings every time the routine is called.
My brain tells me this
shouldn't work, and that it's not a very rational solution. (Hey, let's make a static variable and then always make that a blank variable, as if it was a new one! Nuk! Nuk!) But, when all is said and done, at the end of the day, it clears up the memory problem for me, in this instance.
Whatever is going on with qbs_new, it's not freeing up some memory somewhere. By calling it over and over, that's where we generate our memory leak at.
EDIT:
The more I work with this thing, the more baffling it becomes for me. The following works perfectly fine with the changes above and doesn't generate a memory leak for me:
_TITLE "Test Crap"
DEFLNG A-Z
DO
pass = pass + 1
f = _LOADFONT("cour.ttf", 16)
PRINT pass, f
_FREEFONT f
LOOP UNTIL _KEYHITNow, to break it so that it doesn't work at all, all we have to do is remove the
, f from that PRINT statement. We end up getting an invalid handle error after a few passes with the _FREEFONT command.
Apparently, _LOADFONT really doesn't like the idea of being ran in a loop at all! *grumble* *mumble*
