Weird BASIC problem

[Alan Adams]

[Posted and mailed]

I have a weird problem. A routine which is called successfully hundreds of
times, always from the same place in the code, fails when one of the
passed parameters is not defined. However a call to *reporrtstack from
within the failing routine shows that the variable is being passed in.

My initial reaction was to increase the wimp slot, because this occurs
when a variable in increased, so I have a pretty strong suspicion that
memory is being corrupted somewhere. I don't know where to look though.
What can undefine a variable in this way?

The called function:

DEF PROCFD_SET(n%,p%)
IF DEBUG%AND1 THEN
*report SL: fd_set: n% p% (n% DIV 32) (n% MOD 32)
*REPORTSTACK
ENDIF
p%!((n% DIV 32)*4) = p%!((n% DIV 32)*4) OR (1<<(n% MOD 32))
ENDPROC

The reporter result

SL: fd_set: n%=14 p% (n% DIV 32)=0 (n% MOD 32)=14
BASIC Stack
315 REPEAT
326 PROCreturn13(&00074AC0)
813 PROCnull(&00074AC0)
582 PROCcheckincoming
737 FOR Integer=0 [TO 28 STEP 1]
794 PROCdespatch(0)
1081 WHILE dataend%(client%*2)<>datastart%(client%*2)
1137 PROCsavegates_exec(0)
3122 PROCsendmessage("",0)
3886 PROCsendbuffer(1)
661 PROCFD_SET(14,&00092390) [in "Libraries.Slalom_Comms_Lib"]
11:23:43.17 ** BASICError ** ERR=4 Mistake ERL=435 [in
"Libraries.SocketLib"]
Memory: Prog=153,797 Vars=973,436 Free=146,820 Stack=56 Undefined=0
Slot=1248K

[Alan Adams]

[Posted and mailed]

Hi

Post by Alan Adams
[Posted and mailed]
I have a weird problem. A routine which is called successfully hundreds of
times, always from the same place in the code, fails when one of the
passed parameters is not defined. However a call to *reporrtstack from
within the failing routine shows that the variable is being passed in.
My initial reaction was to increase the wimp slot, because this occurs
when a variable in increased, so I have a pretty strong suspicion that
memory is being corrupted somewhere. I don't know where to look though.
What can undefine a variable in this way?

I've now fixed it. The problem was caused by an incorrectly sized buffer.

The bit that still puzzles me is how *reportstack within the routine
showed a parameter being passed in, yet immediately before and still
within the routine *report showed one of the parameters as not defined.

Post by Alan Adams
DEF PROCFD_SET(n%,p%)
IF DEBUG%AND1 THEN
*report SL: fd_set: n% p% (n% DIV 32) (n% MOD 32)
*REPORTSTACK
ENDIF
p%!((n% DIV 32)*4) = p%!((n% DIV 32)*4) OR (1<<(n% MOD 32))
ENDPROC
The reporter result
SL: fd_set: n%=14 p% (n% DIV 32)=0 (n% MOD 32)=14
BASIC Stack
315 REPEAT
326 PROCreturn13(&00074AC0)
813 PROCnull(&00074AC0)
582 PROCcheckincoming
737 FOR Integer=0 [TO 28 STEP 1]
794 PROCdespatch(0)
1081 WHILE dataend%(client%*2)<>datastart%(client%*2)
1137 PROCsavegates_exec(0)
3122 PROCsendmessage("",0)
3886 PROCsendbuffer(1)
661 PROCFD_SET(14,&00092390) [in "Libraries.Slalom_Comms_Lib"]
11:23:43.17 ** BASICError ** ERR=4 Mistake ERL=435 [in
"Libraries.SocketLib"]
Memory: Prog=153,797 Vars=973,436 Free=146,820 Stack=56 Undefined=0
Slot=1248K

[Martin]

Post by Alan Adams

Post by Alan Adams
[Posted and mailed]

Sorry - been busy (which is nice for a change).

Post by Alan Adams

Post by Alan Adams
I have a weird problem.

[Snip]

Post by Alan Adams

Post by Alan Adams
What can undefine a variable in this way?

I've now fixed it. The problem was caused by an incorrectly sized buffer.
The bit that still puzzles me is how *reportstack within the
routine showed a parameter being passed in, yet immediately before
and still within the routine *report showed one of the parameters
as not defined.

Post by Alan Adams
DEF PROCFD_SET(n%,p%)
IF DEBUG%AND1 THEN
*report SL: fd_set: n% p% (n% DIV 32) (n% MOD 32)
*REPORTSTACK
ENDIF
p%!((n% DIV 32)*4) = p%!((n% DIV 32)*4) OR (1<<(n% MOD 32))
ENDPROC
The reporter result
SL: fd_set: n%=14 p% (n% DIV 32)=0 (n% MOD 32)=14
BASIC Stack

[Snip]

Post by Alan Adams

Post by Alan Adams
661 PROCFD_SET(14,&00092390) [in "Libraries.Slalom_Comms_Lib"]
11:23:43.17 ** BASICError ** ERR=4 Mistake ERL=435 [in

Yo do not clarify what line 435 is ... but I suspect it is the line
above before the ENDPROC?

The 'Mistake' error puzzled me, but then I realised if p% is missing
then because it is on the LHS of line 435 that is the error you see.

The *ReportStack command is showing the value of the *parameters*,
which it gets from a pointer held on the stack to the values and
types of the formal parameters of the routine. It does not have to
look up the variable names. It seems that the values themselves are
correct, so have not been overwritten.

While executing line 435 BASIC will look up the variable names, and
if any of the linked lists for the initial letters of any of the
variables has been corrupted (eg by a buffer overwrite), then the
results are unpredictable.

After a spate of memory overwrites (which can cause some very strange
things) I did consider writing some sort of BASIC Heap validation
check, but never did.

Martin