Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #6178

Weird BASIC problem

Show all headers | View raw

On 30 Jul in article <159f2d9858.Alan.Adams@ArmX6.adamshome.org.uk>,
   Alan Adams <alan@adamshome.org.uk> wrote:
> In message <9695209858.Alan.Adams@ArmX6.adamshome.org.uk>
>           Alan Adams <alan@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. 

Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Weird BASIC problem Alan Adams <alan@adamshome.org.uk> - 2020-07-30 11:32 +0100
  Re: Weird BASIC problem Alan Adams <alan@adamshome.org.uk> - 2020-07-30 13:54 +0100
    Weird BASIC problem Martin <News03@avisoft.f9.co.uk> - 2020-07-31 12:39 +0100

csiph-web