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

Groups > comp.sys.acorn.programmer > #6176 > unrolled thread

Weird BASIC problem

Back to article view | Back to comp.sys.acorn.programmer

Contents

  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

#6176 — Weird BASIC problem

[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
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [next] | [standalone]

#6177

[Posted and mailed]

Hi

In message <9695209858.Alan.Adams@ArmX6.adamshome.org.uk>
          Alan Adams <alan@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.

> 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
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#6178

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. 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web