[FIXED] Glitch between _LOADFONT and PRINT

[SkyCharger001]

Tested.

Can confirm, alteration changes nothing.

PRINT still breaks just like before, with zero change to results.

Stacking overflow from nested functions can be marked off the list of possible problems.

that alteration was only the first step.
step 2 would be to print tempA and tempB, but my understanding of the C-side of the PRINT function is very limited.

So everyone is telling me that you can't reply to posts over in the Bugs section? If I go over there and posting a reply fails, then I'll say SkyCharger was right for once and tell Odin to fix it. Otherwise, don't follow Sky like the pied piper.

The current problem with you is that you seem to assume that what you find is how it has always been ... not a good assumption to make.

Okay, it might help if Odin let us see (a simplified version of) the 'forum bug log' so we can know if a forum-bug we encountered has been dealt with without having to repeat the steps that trigger said forum-bug over and over, but that doesn't 'put you in the right'.

[Cobalt]

just out of curiosity did you have the cour.ttf file in the qb64 folder? I had to put it in mine before loadfont would even work. is it supposed to pull it from the windows\fonts directory? (`ows\` `nts/` `ws\F` all parts of windows\fonts)

[SMcNeill]

just out of curiosity did you have the cour.ttf file in the qb64 folder? I had to put it in mine before loadfont would even work. is it supposed to pull it from the windows\fonts directory? (`ows\` `nts/` `ws\F` all parts of windows\fonts)

Nope.  You should be able to just type "cour.ttf" and have it automatically look in the Windows folder for you for it, in most cases. 

Good eyes catching the output all being part of "Windows\Fonts\", but I'm not certain what that relates to, if anything, with the glitch.  After all, it also generated "-1-" as output (recheck the screenshot), and that has nothing to do with the file path. 

I've just written it off as "Mystery glitch, hopefully fixed".  So far, that seems good enough for me.  ;)

[luke]

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

[STxAxTIC]

Whatever, Sky.

Next time I'm confused about something I'll ask you if I was too busy making assumptions. Where have you been my whole life?

Until such time, Odin will be condensing this topic with the one over in Bugs.

[SMcNeill]

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:

Code: QB64: [Select]

1. int32 func__loadfont(qbs *f,int32 size,qbs *requirements,int32 passed){
2.     //f=_LOADFONT(ttf_filename$,height[,"bold,italic,underline,monospace,dontblend,unicode"])
3.  
4.     IF (new_error) RETURN NULL;
5.  
6.     STATIC qbs *s1=qbs_new(0,0);
7.     STATIC qbs *req=qbs_new(0,0);
8.     STATIC qbs *s3=qbs_new(0,0);
9.     s1 = qbs_new_txt("");
10.     req = qbs_new_txt("");
11.     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:

Code: QB64: [Select]

1. _TITLE "Test Crap"
2. DEFLNG A-Z
3.  
4. DO
5.     pass = pass + 1
6.     f = _LOADFONT("cour.ttf", 16)
7.     PRINT pass, f
8.     _FREEFONT f
9. LOOP UNTIL _KEYHIT

Now, 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*

[Cobalt]

Steve, are you using a DB cause my copy of 1.1 is not behaving the same as what your using?
I have to have the ttf file in the QB folder for one thing, and I'm not getting any odd behavior or memory leakage either.
maybe its the result of something added since the official 1.1 release. or the OS, I still run Vista on my desktop,and  the laptop is running WIN 7.

Good eyes catching the output all being part of "Windows\Fonts\", but I'm not certain what that relates to, if anything, with the glitch.  After all, it also generated "-1-" as output (recheck the screenshot), and that has nothing to do with the file path. 

wasn't sure if it would amount to anything, like maybe a stray pointer out of place, just noticed the correlation to part of it. doesn't explain the blank parts either. All seem to be 4 characters each too(which I guess a SINGLE is 4 bytes and it just sounds like a pointer to me and my limited knowledge of pointers.). hard to check ones that might have spaces though.

Another question though, is QB supposed to be able to have an array of more than 10 (0-9) elements with out DIMing it first? your sample you showed was using 11 elements(0-10).
If its fixed I guess it don't matter, least until it catches up to something else and fails catastrophically! We can always hope though! Without being able to duplicate the error on my end I can't play with it and try to narrow things down so I can't do more than just guess blindly.