How can this error happen?

Watashi kininarimasu

That’s ki ni narimashita to you, Murray-kun.

@nemo

I do not think there is anything I could possibly disagree with.

Nevertheless, it is fun pushing the boundaries. ;-)

Nevertheless, it is fun pushing the boundaries. ;-)

Yes, there’s a difference between encouraging and, well, playing.

That’s ki ni narimashita to you, Murray-kun.

Hai, senpai! ;-)

Thread’s drifted a bit, annit? :-)

Anyway: 7059 STOP has produced “Stopped” on a couple of occasions.

So we’re further on and we’re no further on. There are no GOTOs in the code. You can see the previous lines in the code (and the last non-blank line before that is ENDPROC). So how can line 7059 be executed?

A few things I can think of:

Do you have anything that uses A% to Z%? For some silly reason BASIC doesn’t zero-initialise them on startup, so if you’ve got a code path which is reading from one of them before it’s been initialised then you could be getting some undefined behaviour from that (although it does seem a bit odd that it’s always the same place where it dies).

Maybe try TRACE ON & TRACE OFF around the initialisation code as well? (assuming you can spool the output somewhere useful)

Plus if you can get the output of LVAR when it fails then that might be useful (e.g. launch it via “*BASIC FooFile” rather than the default “*BASIC -quit FooFile”, so that you’re left in BASIC after it finishes)

Dave admitted

Anyway: 7059 STOP has produced “Stopped” on a couple of occasions.

Was the very first response not…?

Execution has fallen into the FN from an earlier line

If you can’t see the lack of END or the predicated ENDPROC or = that’s causing this, stick this at the start:

TRACETO"$.nemoisalwaysright"
TRACEON

and that will allow you work back to where execution leaked from.

Jeffrey said

A% to Z%? For some silly reason BASIC doesn’t zero-initialise them on startup

Apropos of nothing, it is very important indeed to bear this in mind when using one of those BASIC compressors that renames variables.

It is tempting to use a construction like this in a library or highly modular program:

mydata%=mydata%
IFmydata%=0:PROCinitialiseMyData

This can lead to mystified disappointment when the compressor renames mydata% to be an Integer Variable.

BTW, the ‘silly reason’ is that programs can pass integer values to the next program in the CHAIN. This used to be very common when assembling large machine code programs on the Beeb, but I’ve seen it on Arthur and probably RO2 machines too.

@Dave

Jon wrote: Could another variable be overrunning its DIM’d area and corrupting the next variable?

That was my first thought also. However,

nemo wrote: it’s not possible to corrupt the memory between the FN that set the vars and the IF that uses them (unless things have got very bad).

But I would say it is perfectly possible. FNmin looks like a frequently used function, so when first used a% and b% would have been allocated variable space. That variable space is permanent, and will be re-used every time FNmin (or FNmax) is used. That means that there is plenty of time for something to overwrite the a% or b% variable space or even any of the chain of variable names starting in a and b that were allocated before a% and b%. Any time from first use to the errored use will do. The PROC will know where to put its parms without looking up the variable names, I think.

If I was faced with that error (and I have had similar ones several times!) I would first try adding a line
7065 *Report a% b%
which should report lines like
a%=10 b%=20
whenever FNmin is called.
If Reporter cannot find the variable, no value would be given, thus identifying which variable was causing the problem.
Then I would try to identify where that variable was in storage, and what was before it, to check if that could cause a problem.

If the cause was still not obvious, I would write a small PROC which ran down the variable chain to find the missing variable, giving Reports and an error when it could not be found. This could be run at frequent intervals within the program, and after different pieces of code, to narrow down what code caused the variable to be lost.

There is also a *ReportMon command, which monitors specified variable values at the start of each line and reports if they have changed – that may help, but I have not tried in this circumstance.

I suspect when the bug is found it will be obvious … finding it may take a while!

Apologies if you are not using Reporter to help debugging a BASIC program!

That means that there is plenty of time for something to overwrite the a% or b% variable space or even any of the chain of variable names starting in a and b that were allocated before a% and b%.

We have already established that execution is falling into the function:

Anyway: 7059 STOP has produced “Stopped” on a couple of occasions.

This is highly artificial and almost certainly does not represent what you have, but it does reproduce the error.

PRINT FNmax(1,2)
END
7040 DEFFNmax(A%,B%)
7050 IF A%>=B% THEN =A% ElSE =B%

7060 DEFFNmin(a%,b%)
7070 IF a%>=b% THEN =b% ELSE =a%

It illustrates the clumsy way that BASIC interprets IF...THEN...ELSE.

I do not think it can be the source of your error, but another possible problem is that BASIC searches for the next ENDIF or ENDCASE if there is not one at the end a structure, and this can mean jumping out of a DEF into another further on in the program.

execution is falling into the function

I missed the STOP messages. If it can execute 7059, and it has not got there from a GOTO, then it seems it has fallen through 7050. However, if at that time it was in a Function, then it would have returned from the THEN or ELSE. If it was not in a Function, it would have errored at 7050 with ‘Not in a Function’. Something is not as it seems. We need to find how it arrived at the STOP. *ReportStack would display the current outstanding PROCs or FNs on the stack at that point.

But I still bet on memory corruption somehow somewhere.

This is highly artificial

There’s so many lovely little things like that, yes.

I wonder if it’s a CC instead of an 8B.

What if it was somehow falling into the first DEF FN as well?

Eventually I’ve found what’s going wrong. The code gets data in from a TCP socket. These data contain several text records, each terminated by CR. My code looks for the CR to determine how many bytes must be base64 decoded. However, in some cases the data are delivered to the app incomplete, so the CR hasn’t been delivered, so the search finds the first CR in goodness knows what data. The base64 decode then proceeds to decode 400-odd kbytes of data into an otherwise very generously sized 8kiB buffer.