"Out of Memory" mystery

[OldMoses]

Thank you, Steve. That works perfectly in the application. It's behaving itself now. Would that be a QB64 issue then?

That also explains why my character handling program doesn't have this issue, it uses no TABs. Certainly not loop called ones.

Entry_Print, with it's TAB statements, has been around since the very early days of development. The application is at least 20 years old, and most likely older. It was only later that I got more into using LOCATE for output formatting. In fact, I wasn't aware that row references in LOCATE were optional, so I will be excising TAB from my coding efforts for a while.

I think what happened to the EXEICON was that I compiled the program when the ico file was in the root directory. I later moved all image files to the 'images' directory but forgot to change the path to the ico. I'm kinda like a dwarf playing in his treasure hoard, so intent upon playing with the shiny baubles that he forgets to take a potty break...poor coding hygiene....

I also want to shout out a big thank you to Terry again, I never thought of Task Manager as a debugging tool before he suggested it. I wouldn't have had a clue without it.

[Pete]

Removing the use of TAB corrects the issue.  Apparently TAB has a memory leak in it somewhere:

Code: QB64: [Select]

1. DO
2.     Entry_Print
3. LOOP
4.  
5.  
6. SUB Entry_Print '(entry AS LoadRecord)
7.  
8.     '-------------------------DISPLAY----------------------------------------------------
9.     ' SUB: Entry_Print
10.     '
11.     ' Purpose:
12.     ' Displays tabbed data from record number passed by 'entry' when called.
13.     '
14.     ' Passed parameters:
15.     ' entry sends the load record for display
16.     '
17.     ' Called from:
18.     ' Add_Record, Edit_File, Refresh_Screen, and View_File
19.     '
20.     '-----------------------------------------------------------------------------------
21.  
22.     LOCATE , 1: PRINT USING "###   "; entry.load;
23.     LOCATE , 6: PRINT entry.Date;
24.     LOCATE , 17: PRINT entry.Time;
25.     LOCATE , 28: PRINT RTRIM$(entry.truck$);
26.     LOCATE , 37: PRINT USING "###,###"; entry.Gross;
27.     LOCATE , 45: PRINT USING "###,###"; entry.Net;
28.     LOCATE , 54: PRINT USING "#,###.##"; entry.Wet;
29.     LOCATE , 64: PRINT USING "##.##"; entry.Test;
30.     LOCATE , 70: PRINT USING "#,###.##"; entry.Dry
31.  
32. END SUB 'Entry_Print
33.  

I mentioned the possibility of a memory leak, but wow Steve, you hunted that down fast! I hope it can be fixed in an upcoming version of QB64. Tab isn't used much, I suspect, so it doesn't surprise me if this is a memory leak, it hasn't been found until now.

I remember when I used to debug programs while Rob was developing. If my program threw an error, and I knew it wasn't coming from my code, I had to piece by piece eliminate things in the code until I removed a line that removed the problem. Then I'd report it so it could be fixed. Ah, those were the days... and I don't miss them one friggin' bit!

Pete :D

[OldMoses]

I've had a chance to run the program in its working environment this morning, running Task Manager in the background. It was still ticking up slightly, although it would have taken a week of constant running to fill up. I went looking for more TABs and found a few in the loop associated with printing out totals. After removing them, it holds steady at under 40 MB when not actually processing input.

It would seem to confirm that TAB is a troublemaker.

[SMcNeill]

Thank you, Steve. That works perfectly in the application. It's behaving itself now. Would that be a QB64 issue then?

It is.   I took a look inside libqb last night and found the function for tab (func_tab, maybe?  I was half asleep and don't remember the exact name for it...).   From initial impressions, I'm going to assume it's similar to the memory leak PRINT used to have:  it looks as if the routine uses qbs_new to allocate memory for a few temporary QBStrings, but then it doesn't qbs_free them.

The fix may be as simple as freeing the strings before leaving the routine, and if so, somebody should be able to sort that glitch out rather quickly and push the needed change into the repo.   ;)