Possible BASIC EVAL or Reporter issue

I’m using the latest version of Reporter with BASIC 1.85 (the current OS build on a Pi) to try and diagnose BASIC stack corruption I’m seeing in Partition Manager. If the output of Reporter is correct, EVAL is corrupting the BASIC stack.

Could someone please try the Repro below with Reporter running and see if either Aborts, or shows a corrupt BASIC stack.

PROCtest
END

DEF PROCtest
  LOCAL V%

  DIM V% LOCAL 8192
  *ReportStack
  A%=EVAL("0")
  *ReportStack
ENDPROC

Running that here I get…

BASIC Stack
     2 PROCtest
       DIM LOCAL 8196 bytes
     2 PROCtest
BASIC Stack
     2 PROCtest
       DIM LOCAL 8196 bytes
     2 PROCtest
Reporter 2.74 (01 Aug 2021) © Martin Avison, 2000-2021
BBC BASIC V 1.85 (03 Oct 2022)

However, very occasionally I have seen an abort with your program!
I hate bugs which hide. I will try and provoke it to appear again here.
And I will investigate the apparent ‘corruption’.

If you get an abort, can you do a *ReportWhere (or use the menu) and send me the output please?

Now try this Repro

PROCtest
END

DEF PROCtest
  LOCAL V%

  *ReportStack
  A%=EVAL("0")
  DIM V% LOCAL 8192
  *ReportStack
ENDPROC

Here’s the ReportWhere output I get:

13:03:31.11 Basic -quit "SDFS::RISCOSpi.$.EVAL,ffb" 
BASIC Stack
     4 PROCtest
BASIC Stack
     4 PROCtest
13:03:31.18 ** Error **
  Error  : &80000002
  Message: Internal error: abort on data transfer at &20382434
13:03:31.18 ** Error **
  Error  : &80000002
  Message: Internal error: abort on data transfer at &20382434
13:03:31.18 ** Error **
  Error  : &80000002
  Message: Internal error: abort on data transfer at &20382434
13:03:31.18 ** WimpError ** from unknown task
  Error  : &80000002
  Message: Internal error: abort on data transfer at &20382434
Address &2038243C in Module   Reporter            @ &2037B6B4 + &6D88
                  in Function Stack               @ &20382308 + &134
Register dump (at &20003110) is:
pc  = &2038243C  Flags=&20000110=nzCv if  Mode=User 32 bit
r0  = &00000000 :          0
r1  = &000A7F38 :     687928 => &000000F2 : ò... : 242
r2  = &000A5FA4 :     679844 => &00000006 : .... : 6
r3  = &000000F2 :        242
r4  = &000000F2 :        242
r5  = &20376194 :  540500372 => &20203572 : r5   : 538981746
r6  = &00000000 :          0
r7  = &20382518 :  540550424 => &5008F2F2 : òò.P : 1342763762
r8  = &00000000 :          0
r9  = &00000000 :          0
r10 = &00000052 :         82
r11 = &3011D6E0 :  806475488 => &00000000 : .... : 0
r12 = &20375B94 :  540498836 => &44070017 : ...D : 1141309463
r13 = &000A5F40 :     679744 => &000A7F38 : 8... : 687928
r14 = &20382470 :  540550256 => &E8BD0206 : ..½è : 3904700934
Code around address is:
20382404 : E92D0206 : STMDB   R13!,{R1,R2,R9}
20382408 : E5D73002 : LDRB    R3,[R7,#2]
2038240C : E3A06000 : MOV     R6,#0
20382410 : E3530000 : CMP     R3,#0
20382414 : 03A00007 : MOVEQ   R0,#7
20382418 : 0A00000D : BEQ     &20382454
2038241C : E5910004 : LDR     R0,[R1,#4]
20382420 : E3100102 : TST     R0,#&80000000
20382424 : 1A000013 : BNE     &20382478
20382428 : E3530004 : CMP     R3,#4
2038242C : 17910003 : LDRNE   R0,[R1,R3]
20382430 : E5D73001 : LDRB    R3,[R7,#1]
20382434 > E5702001 > LDRB    R2,[R0,#-1]!
20382438 : E1520003 : CMP     R2,R3
2038243C : 1AFFFFFC : BNE     &20382434
20382440 : E2803001 : ADD     R3,R0,#1

@Jon. I think I have found the issue. In your first Repro, when PROCtest is called, an entry is added to the stack. Then, when the DIM LOCAL is executed, it is copied ~8192 bytes down the stack. Reporter finds the initial entry for PROCtest and displays it, then the DIM LOCAL entry, then the actual entry for PROCtest. This is the ‘stack corruption’ you may see. Worse, the 8192 bytes added to the stack will be random data, and that could confuse Reporter and cause an abort. The full stack contents can be seen by adding the L parm to the *ReportStack.

Both problems can be avoided if the V% block is initialised before *ReportStack.
I think this is a limitation caused by the stack being designed to be read bottom up, and Reporter trying to interpret it top down.

Are you saying this should be okay:

PROCtest
END

DEF PROCtest
  LOCAL V%
  DIM V% LOCAL 8192
  *ReportStack
ENDPROC

No. It may not abort, but it will still show two PROCtest on the stack.
And if you add an L parm to *ReportStack you will see them both for yourself (as long as your Reporter text size is over 60K).

Add after the DIM LOCAL eg:
FOR I%=0 TO 8192:V%?I%=&84:NEXT
and all will be well.

I think the short version of this is “Reporter doesn’t know about DIMxLOCALy and is therefore trying to recognise its memory contents with insufficient checking instead of stepping over it”.

Or to put it another way, the reason that Basic doesn’t unwind its stack is that it is not possible to unwind Basic’s stack – even when you are cognisant with how the currently running interpreter uses R13.

I’ve previously acknowledged that there are problems with DIMxLOCALy, but primarily with its interactions with pseudo-LOCALs like LOCALERROR (a significant failing), and the totally incompatible strategy employed by LOCALa():DIMa(1). To say nothing of the horrors of SWAP.

But this seems to be a phantom imagined by Reporter.

But this seems to be a phantom imagined by Reporter.

Not imagined. There are two tokens for PROCtest, with their return and id pointers, on the stack. However, I admit that Reporter should not be looking at one of them, as it is in the middle of the DIM LOCAL data area! I know there are problems when trying to unwind the stack, but I will try and educate Reporter about this one.

I will try and educate Reporter about this one

If you could that would be great as it’s issues with DIM LOCAL that I’m trying to diagnose.

Martin mentioned

Not imagined. There are two tokens for PROCtest

Pedantic: There aren’t – one is a token, one is just a byte inside a DIM.

The reason that Basic does not unwind its stack on error is that it is not possible – there can be any amount of unidentifiable guff on the stack, especially during expression evaluation. So it is never possible to safely proceed beyond an &A4 FN structure, as there can be anything underneath – string bytes, working registers from any number of command, maths and evaluation functions, even arbitrary contents from machine code that has called EXPR.

You might build a heuristic that works most of the time with the version of the interpreter you’re familiar with, but it cannot be reliable because the stack contents cannot be groked.

I fixed the LOCAL bug in my version of Basic by forming a sequence of linked stack frames for LOCALs, which allows that element of the stack contents to be unwound on error. But even between those provable frames the content can be inscrutable.

The reason that Basic does not unwind its stack on error is that it is not possible

Yes, I realise it cannot be done for every possible circumstance.
But for most debugging of BASIC programs, there are times when seeing even a best interpretation of the stack has been invaluable to me, and I know to many others.

If you could that would be great as it’s issues with DIM LOCAL that I’m trying to diagnose.

I do not have your email address, so if you PM me at my name in Reporter Help with some details, I will try to help.

PM me

Done

even a best interpretation of the stack has been invaluable to me, and I know to many others.

For example, a library routine triggers an error. Since it’s probably caused by the input conditions, knowing which of many possible places it was called from is more than helpful.

Many of mine now contain:

IF <INPUT VALUE> = "" THEN
  *reportstack
  ENDPROC
ENDIF