Possible BASIC EVAL or Reporter issue
Jon Abbott (1421) 2641 posts |
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.
|
Martin Avison (27) 1491 posts |
Running that here I get…
However, very occasionally I have seen an abort with your program! If you get an abort, can you do a *ReportWhere (or use the menu) and send me the output please? |
Jon Abbott (1421) 2641 posts |
Now try this Repro
Here’s the ReportWhere output I get:
|
Martin Avison (27) 1491 posts |
@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. |
Jon Abbott (1421) 2641 posts |
Are you saying this should be okay:
|
Martin Avison (27) 1491 posts |
No. It may not abort, but it will still show two PROCtest on the stack. Add after the DIM LOCAL eg: |
nemo (145) 2529 posts |
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 But this seems to be a phantom imagined by Reporter. |
Martin Avison (27) 1491 posts |
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. |
Jon Abbott (1421) 2641 posts |
If you could that would be great as it’s issues with DIM LOCAL that I’m trying to diagnose. |
nemo (145) 2529 posts |
Martin mentioned
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. |
Martin Avison (27) 1491 posts |
Yes, I realise it cannot be done for every possible circumstance. |
Martin Avison (27) 1491 posts |
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. |
Jon Abbott (1421) 2641 posts |
Done |
Alan Adams (2486) 1147 posts |
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:
|