+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: program crashes about 20% of the time (/showthread.php?tid=1301)
RE: program crashes about 20% of the time - Pete - 12-18-2022
I could channel Clippy on this OP, but I just remembered... It's Christmas, not Halloween.
Pete
RE: program crashes about 20% of the time - mdijkens - 12-18-2022
This really looks like it started as Basic, then migrated to qbasic then to qb64...
Done this a few times myself.
Always start refactoring code to remove goto and gosub and localize variables with strong typing.
It takes some time, but you win that back in the long run....
RE: program crashes about 20% of the time - mnrvovrfc - 12-18-2022
(12-18-2022, 06:50 PM)mdijkens Wrote: This really looks like it started as Basic, then migrated to qbasic then to qb64...
Done this a few times myself.
Always start refactoring code to remove goto and gosub and localize variables with strong typing.
It takes some time, but you win that back in the long run....
No need to get rid of "GOTO" and "GOSUB... RETURN" but have to keep track of it carefully. Please don't make QB64(PE) more like Freebasic and Visual Basic for some people.
"ON... GOTO" and "ON... GOSUB" have a way to induce bad habits too. I agree those should be replaced by "SELECT CASE... END SELECT" which is far more readable and easier to control.
A programmer who cannot decide between "GOTO" and "GOSUB" to jump around in code should stop insisting on it. Put the "subroutine" block into a subprogram that could be called by name. Because using "GOSUB" must have a "RETURN" around somewhere. Please remember that in Q(uick)BASIC, and later on in QB64(PE) line numbers are not required, and therefore there is no sense in programming as if the opposite were true. Cannot hate "RETURN without GOSUB" interpreter error message that much as an excuse not to force "subroutines" to be self-contained, or as an excuse to not create subprograms of any kind.
I agree with the strong typing except for people very used to implicit declarations of variables. Again, things have to be examined more carefully because it's left entirely at the programmer's disposal. "OPTION _EXPLICIT" could only do so much, and some coders have a problem with it.
RE: program crashes about 20% of the time - bplus - 12-18-2022
GOTO is nightmare to debug except in very small self contained blocks of code.
Too many GOSUBs and you are bound to trip over your main code variables, stick with safe local variables in subroutines. Specially when have over 2500 LOC! Routines can be tested independently and once debugged likely to stay debugged.
Besides that's not the issue with this code.
Billy has to narrow down what is causing problems. Crash without error messages does sound like memory leak or stack going past it's storage capacity because of repeated calls either recursively or unintentionally.
I like what Pete said, test like an electrician from start to point A and move point A down the line until error is isolated.
RE: program crashes about 20% of the time - mdijkens - 12-18-2022
Picked it up... trying to run it now
after some minor changes; have it running
Created customer and order for small pizza.....
When is it crashing? how to recreate the issue?
Any steps I can do to have it crash?
RE: program crashes about 20% of the time - mdijkens - 12-18-2022
Noticed in Sub CUSTINFO several very tricky things are going on....
GoSub FUNCTIONS does not always Return "If KEYPRESS = 27 Or T = 27 Then Exit Do" is a serious NO
In general this Sub is very spaghetti-like and really hard to test if it does not create stack/heap overflows
I'd start restructuring Sub CUSTINFO
RE: program crashes about 20% of the time - Pete - 12-18-2022
+1 for effort. Even without missing a RETURN you can burn up your stack space by deeply nested GOSUB statements that run in a loop. The system has to keep piling all those other sub calls and gosubs on top of the first non-returned GOSUB. No nice way to say it, that's just a programming trap and the OP probably fell in it if this does turn out to be a stack space crash issue. Again, running task manager and checking memory alongside the running app would be beneficial. I miss how QuickBASIC was able to track stack space with FRE().
Pete
RE: program crashes about 20% of the time - Jack - 12-19-2022
@billythebull, try the following to increase the stack size
click on C++ Compiler Settings and then in the C++ Linker Flags paste -Wl,--stack,16777216
RE: program crashes about 20% of the time - bplus - 12-19-2022
Is there a way to beep or create message when stack is be taken to limits and say trace it back to the routine or line number doing it? perhaps on error something....
RE: program crashes about 20% of the time - Pete - 12-19-2022
(12-19-2022, 12:31 AM)Jack Wrote: @billythebull, try the following to increase the stack size
click on C++ Compiler Settings and then in the C++ Linker Flags paste -Wl,--stack,16777216
In QuickBASIC we just used: CLEAR , , 2000 to increase the stack. I can't even imagine needing CLEAR , , 16777216. Not that we can do that in QB64. Maybe some dev should put that option back in place. As it is now, QB64 ignores the memory parameters in CLEAR.
Pete