NOT ENOUGH MEMORY TO EXECUTE QB64 PROGRAM

[lstyle7400]

I compiled an existing QB45 program into QB64.  The QB45 program runs well.  This program would not execute originally because the source code used too much memory.  I then broke the program into subroutines and the program executes well in QB45.  QB64 when it compiles takes QB45 subroutines and places them into one executable code main module.  Subs are contained within the QB64 main code module.  When the compile happened, the code would not run because no memory for the code.  So this is where I started originally in QB45 before breaking the code into sub-routines which are separate from the main module in QB45 but added to the main module in QB64.  Is there a way to run subs in QB64 so they are not added to the main module so the main will execute without not enough memory error?

[Bert22306]

Subs are contained within the QB64 main code module.  When the compile happened, the code would not run because no memory for the code.

I'm not sure why the subroutines are going into the main module, in QB64, if they were separate subroutines in QB45.

One thing to keep in mind is that QB64's IDE indeed shows all of the subroutines following the main module, without mandating that you press the F2 key to go to each sub separately. Using MS QB, you got the impression that subroutines were in some totally different location. However, those subs are still subs, in QB64, when the program is compiled. (As far as I know. Steve or others will soon correct me if I'm making a bad assumption here!)

Is there a way to run subs in QB64 so they are not added to the main module so the main will execute without not enough memory error?

The memory error, I have to believe, is completely unrelated to how the IDE shows the subroutines. Could it be some undimensioned array, or using the same variable name for an array and a single variable, or other oddities like that? These error notifications come from the C++ compiler used in QB64, and they can be pretty obtuse.

I did notice, when I started using QB64, that in some ways, the QB7.1 I was using previously was more forgiving. In multiple programs, if I was trying to be too tricky with my code before, QB64 would flag an error. Luckily for me, this happened on relatively short programs that I managed to fix with minimal effort. Even silly things, like where to use parentheses in a statement, managed to create problems for me.

Next thing you can expect is that people will want to see the code, to find the problem. But I'm betting on some dumb syntax problem, which causes this "memory error" notification.

[SMcNeill]

Next thing you can expect is that people will want to see the code, to find the problem. But I'm betting on some dumb syntax problem, which causes this "memory error" notification.

I, for one, would love to see the code, just to see what causes such an error.  ;)

QB45 has very low memory limits, and I remember us having to break projects into multiple sub-projects and CHAIN between them, back in the day.  QB64, on the other hand, can use as much memory as our PC contains — I, personally, have written, compiled, and ran programs that used about 8GB of memory with no problems.  (QB45 had a 640kb memory limit, if I remember correctly, for comparison.)

The only think I can imagine which would give an “Out of Memory” Error, would be a memory leak somewhere, such as creating a screen over and over inside a loop, without freeing the old one as you do so, like in the simple code below:

Code: [Select]

DO
    SCREEN _NEWIMAGE(640, 480, 32)
LOOP

[Pete]

My hunch is something isn't right from the converting process. It's been too many years ago, but I recalled I had to be careful when converting my multi-modular programs to one large QB64 program. Also, QBasic / QB4.5 used to give an out-of stack space error, as well as an out-of-memory error. You ran out of stack space if you used GOTO to pop out of a recursive GOSUB, something like this...

Code: QB64: [Select]

1. CALL keyroutine
2. SUB keyroutine
3.     DO
4.        101
5.         b$ = INKEY$
6.         IF b$ = CHR$(27) THEN END
7.         GOSUB stack
8.     LOOP
9.     stack:
10.     GOTO 101 ' Does not allow the stack to unload...
11.     RETURN
12. END SUB

Something like a recursive sub call could do the same, if I recall correctly...

Code: QB64: [Select]

1. CALL keyroutine
2. SUB keyroutine
3.     DO
4.         b$ = INKEY$
5.         IF b$ = CHR$(27) THEN END
6.         CALL keyroutine
7.     LOOP
8. END SUB

In any event, QB64 has tons more memory. Both Steve and I have single QB programs around 100,000 lines, without any memory issues. So, again, my hunch is some memory leak may have entered into the conversion from QB4.5, and there is also the possibility the memory leak may be a yet not discovered QB64 bug. We'd really have to have the code, to see what's going one here. If it's too large to post, it could be placed in a zip file and uploaded as an attachment.

Pete

[Bert22306]

My hunch is something isn't right from the converting process. It's been too many years ago, but I recalled I had to be careful when converting my multi-modular programs to one large QB64 program.

The memory leak suggestion sounds like a good bet. On the other hand, I don't think that Istyle2400 has actually converted the QB4.5 program into just one main module. My guess was that he was surprised to see all the subs showing up in the IDE, along with the main module, without having to use the F2 key. My read of his experience is that he is just trying to run the same code, which worked fine in QB4.5, over QB64.

I was also surprised by how the subs show up in the QB64 IDE, at first. Of course, I soon came to prefer QB64's IDE. For that, and for a ton of other reasons, over time.

So, if the QB4.5 program did not experience a memory leak, but for some subtle syntax-related reason, the same code running on QB64 does experience a memory leak, I would not be overly surprised.

[SMcNeill]

Without the code, all we can do is speculate on possible issues.  It’s entirely possble that the code fails to work properly due to some unemulated commands.  An example I can think of, off the top of my head, would be various PEEK/POKE addresses.

DIM X AS LONG, Y AS LONG
DO
    X = X + 1
....stuff
LOOP UNTIL X = PEEK(&H20)

In QB45, the peek above would tell you the width of the active screen.  QB64 has the _WIDTH command and fails to emulate this old PEEK statement.  In QB45, the program would run just fine; in QB64, it’s a loop with 4+ billion cycles, before it overflows and reaches 0...

I can definitely see such a glitch leading to an out of memory error — particularly if Y was configured the same way and had the same problem.  ;)

[Ryster]

SMcNeill: "Next thing you can expect is that people will want to see the code, to find the problem. But I'm betting on some dumb syntax problem, which causes this "memory error" notification."

I waited for several years for the improvement of QB64 due to lack of memory. My source code was also suspicious, but I never published it because it was written correctly. So after a few years SmcNeill was kind to improve QB64, which is now working properly and does not report any memory leaks. I wonder what version "Istyle 7400" uses. I don't think because of the source file size. My file currently has over 66,000 lines of code and is compiling correctly. I recommend the QB64x64 version.

Ryster.

Happy New Year 2020.

[Pete]

Good point about the version, and the need to be up to date. Who knows. He might have downloaded some version from a couple of years ago, but never got around to trying it until now. I suppose anything is possible.

@lstyle: As far as debugging it. If you don't want to share the code, it's pretty simple to find the bug. Just re-assemble the QB64 program, one part at a time, from the QB4.5 program. Run it each time until you get the error. You may need to post that much of it, or at least the added part that caused the memory error to appear. Of course, you might just be able to figure it out for yourself at that point.

Pete