|
|
Post by jlthompson on Apr 23, 2018 5:44:44 GMT
I have a large program, and when I added and debugged a new subroutine, it compiled, started the program, and then stopped with an "out of memory unable to continue" message. What does this mean?
|
|
|
|
Post by tsh73 on Apr 23, 2018 6:29:15 GMT
Well, I dunno, it eat up all available memory?
I's really hard to say without seeing code.
Have you tried closing JB and opening it? Restarting Windows?
Have you use JB 2.0? It has much more memory (about 10x EDIT 256Mb) then JB 1.01 (70Mb).
Does your program worked before what new sub?
What is "large" program?
Is new sub doing anything of
* hold big strings,
* big arrays,
* constantly draws on screen without DISCARD or CLS
* recursively calls itself
?
|
|
|
|
Post by jlthompson on Apr 23, 2018 6:38:16 GMT
No idea how I'd check if it's eating up all available memory. I have restarted everything. The program worked before the new subroutine. By large, I mean over 59,000 lines. All the subs hold large arrays and strings. No recursive calls, no drawing. Haven't tried JB 2.0 yet. Does it change any command functionality?
|
|
|
|
Post by tsh73 on Apr 23, 2018 7:24:06 GMT
I used to look at program in Process Explorer
If memory usage constantly grows that's a bad sign, showing memory leak, likely ending with Out of Memory or something.
On Win10 probably Task Manager will be enough
(wow, I just found extra JB process on my computer - leftover from crashed program, likely)
Wow. Much bigger then I ever tried!
I didn't notice
But it adds some nice things - native SORT, some sprite commands, STRINGWIDTGH,
better editor, better debugger,
may be more - read What's new
|
|
|
|
Post by Rod on Apr 23, 2018 13:17:05 GMT
CtrlAltDel together you will get the option to start the task manager. Then start your program, you will see it appear as a process in the task manager. You will see the memory it is using. Just firing up the IDE will use about 6Mb of memory. What is your program taking when it first starts?
There is the possibility that you have a bug writing a very large string. Make your program wait at specific points in your process and watch how the memory builds.
|
|
|
|
Post by cundo on Apr 23, 2018 17:21:10 GMT
If your code worked fine before, we should check that subroutine for sure, at least.
|
|
|
|
Post by B+ on Apr 24, 2018 13:47:47 GMT
By using word subroutine, I am thinking you are calling it by line number that you don't have it isolated into a modular sub that takes a "CALL".
If program is 59,000 lines and it's all line labeled subroutines, you could save some memory by modulating the routines as all variables inside a modular routine are throw aways when you exit the sub, not so with line labeled called subroutines.
Can you test the routine isolated from the rest of the program? You could verify the routine is fine and the memory problem is due to huge size of program, ie the last routine added was "the straw that broke the camel's back" as far as memory capacity goes..
|
|
|
|
Post by jlthompson on Apr 24, 2018 19:04:47 GMT
"'By large, I mean over 59,000 lines.'
Wow. Much bigger then I ever tried!"
It's taken me over ten years to program it.
OK, it looks like my only real choice is trying JBv2. As the program involves many computers networked together, accessing common files, I hope to make as few changes as possible, and I want to know what I'm doing before making the change. Where can I find a link to download it, and a record of all the changes made to it?
|
|
|
|
Post by tsh73 on Apr 24, 2018 19:36:56 GMT
|
|
