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, from Northamptonshire
al...@adamshome.org.uk
http://www.nckc.org.uk/

[Alan Adams]

[Posted and mailed]

Hi

In message <9695209858...@ArmX6.adamshome.org.uk>

Alan Adams <al...@adamshome.org.uk> wrote:

> [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.

[Martin]

On 30 Jul in article <159f2d9858...@ArmX6.adamshome.org.uk>,

Alan Adams <al...@adamshome.org.uk> wrote:
> In message <9695209858...@ArmX6.adamshome.org.uk>
> Alan Adams <al...@adamshome.org.uk> wrote:
> > [Posted and mailed]

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

> > I have a weird problem.

[Snip]

> > 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.

> > 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

[Snip]

> > 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

--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.