D3 array subscript error. What am I missing?

[Kevin Powick]

I have a program in D3 (9.1.0) giving me an array subscript out of range error that I cannot figure out because both the subscript and the array appear to be defined.  

The offending line is 340, with code and debugger info as follows:

340 BOXES = LREC(SPOS)

*G [B17] in program "ASN.KKP", Line 340:  Array subscript out-of-range.

*I340 

*/SPOS 4=

*/LREC(4) 1]2^4000207321\4000373501\4000373502\4000373555\4000376846]4000376847\4000453061^2\3\2\2\6]9\3=

LREC(4) looks good to me. In fact, LREC is dimensioned and populated up to LREC(12).  

Maybe I've spent too much time in front of the screen, because this usually obvious error is not so obvious to me today.

Ideas appreciated.

--

Kevin Powick

[Kevin Powick]

It now looks like this may be a D3 bug, because when I flash compile the program, option (o), the error disappears and the program works as expected.

I've seen errors in flashed code before, but I do not recall a time when errors were corrected by flashed code.  Odd indeed.

I'll keep plugging away at this issue, but I'm still interested to hear from anyone that has run into similar problems with dimensioned arrays. 

--

Kevin Powick

[Tony Gravagno]

In each occasional releases there are issues where code or data cross a frame boundary. So adding a few NULL statements might move the object code down a few bytes and avoid that specific error. That doesn't help with a data issue but it would be interesting to know what kind of issue this is.

The FlashBASIC compiler is really a completely separate animal from Interpreted BASIC. Our normal BASIC compile uses source code as input and it produces tokens for output. FlashBASIC uses tokens for input and it produces another completely different object module for output. The normal BASIC runtime uses tokens for input and processes the code with D3 Assembler (Pick Virtual Assembly, PVA...) while FlashBASIC calls to external C code to execute the instructions. (I'm not 100% sure of a couple minor details in there but for the most part that's accurate - I'm not in tune with exactly how much integration there is between C and PVA through the px.resume modes.)

Given all of that, it should be no surprise that they work very differently, have different debug capabilities, etc. Your source code is the same but after that nothing is the same underneath. It's not that FlashBASIC fixes anything or breaks anything, any more than riding in a Honda will fix or break the ride from a Toyota - it's just a different ride.

All that said, in addition to speed benefits I think the hope always was that completely re-writing the BASIC compiler and run-time would eventually lead to new features and fixes that were too tough for the old compiler. So personally I always try to look to Flash as being the new and improved version.

And finally, I'm hoping you can report the issue. 9.1 isn't very old and 9.2+ might have the same issue. So you'd be doing everyone a favor if you could report it with a reproducible bit of code. Curiously, whittling down your code to create a reproducible condition can be exactly the process that eliminates the condition forever.

HTH
T

[Kevin Powick]

Thanks for the feedback, Tony.

I know what change in my code caused the issue, and agree that it is these two completely different forms of BASIC that allows one version to run, but not the other.

The routine was working at one time, but needed to be updated to accommodate a new feature.  There was a piece of in-line code that I moved to an internal subroutine because the new feature being added could take advantage of that same, in-line code.  The subroutine actually returns the populated, dimensioned array that now causes a problem when the program is not Flashed.  As you noted, something may no longer line up or the call stack is "confused".

I will try adding some null lines, and I hope to be able to create a simplified test case that reproduces the error for Rocket support.

--

Kevin Powick

[Peter McMurray]

Hi Kevin

If one routine is optimised then they all have to be.

[Kevin Powick]

On Tuesday, 9 September 2014 17:35:56 UTC-4, Peter McMurray wrote:

If one routine is optimised then they all have to be.

Thanks, but If you're referring to the subroutine I mentioned, it is internal to the main program.  No external CALLs are being made.

--

Kevin Powick 

[David Knight]

Are you by any chance with the multiple-call to a subroutine [section] redimensioning the array? I'm far from an expert, but that's perhaps what I'd be think of.... I vaguely remember something about memory handling and dimensioned arrays; destroying and recreating them etc. IIRC it's like a COMMON issue - bits get overwritten that you were not expecting??

On Tuesday, September 9, 2014 10:08:36 AM UTC+10, Kevin Powick wrote:

[Peter McMurray]

Hi Kevin

I should have noticed the word internal,sorry about that. I was thrown by the statement that it was to be used elsewhere.

[Kevin Powick]

David,

On Tuesday, 9 September 2014 20:46:59 UTC-4, David Knight wrote:
Are you by any chance with the multiple-call to a subroutine [section] redimensioning the array?

Yes, but not only is re-dimensioning allowed in D3, I've discovered that this is not the cause of the issue.

The problem appears to be caused when dimensioning an array with a variable for the size, but only if done within a subroutine.  Dimensioning with a variable outside the subroutine, or inside the subroutine with a constant, does not cause any problems.

Below are simple test cases that illustrate the problem. It would be great if others could try them on their version of D3.  My tests were run on 9.1 and it is only the non-flashed version that fails.

** Test 1 - DIM() inside subroutine 

** with a constant - PASS

MAXX = 5

GOSUB CALC

FOR JJ = 1 TO MAXX
   CRT REC(JJ)
NEXT JJ
STOP
*
CALC:
DIM REC(5)

MAT REC = ''
FOR JJ = 1 TO MAXX
   REC(JJ) = JJ
NEXT JJ
RETURN

** Test 2 - DIM() inside subroutine

** with a variable - FAIL

MAXX = 5
GOSUB CALC
FOR JJ = 1 TO MAXX
   CRT REC(JJ);* fails here
NEXT JJ
STOP
*
CALC:
DIM REC(MAXX)
MAT REC = ''
FOR JJ = 1 TO MAXX
   REC(JJ) = JJ
NEXT JJ
RETURN

** Test 3 - DIM() outside subroutine

** with a variable - PASS

MAXX = 5

DIM REC(MAXX)

GOSUB CALC
FOR JJ = 1 TO MAXX
   CRT REC(JJ)
NEXT JJ
STOP
*
CALC:
MAT REC = ''
FOR JJ = 1 TO MAXX
   REC(JJ) = JJ
NEXT JJ
RETURN

Although test #2 fails with an "array subscript out of range" error, when the program drops into the debugger, examining the contents of the array REC(), shows that it is populated as expected.

--

Kevin Powick

[Glen Batchelor]

set the dim to null before assigning a value and try it again.

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Kevin Powick]

On Tuesday, 9 September 2014 23:18:48 UTC-4, GlenB wrote:

set the dim to null before assigning a value and try it again.

Not sure what you're stating.  Care to provide a code example?

I've actually posted a more simplified version of my tests to the D3 forum at Rocket, where I do not MAT REC = '' before populating it.  The result it the same. 

--

Kevin Powick

[Glen Batchelor]

PTR=PTR+1
DIM VAR.A(PTR)
VAR.A(PTR)=""
VAR.A(PTR)=My.Dyn.Array

I have seen re-dims blow up on unassigned dims being used. Dunno why the null matters but it even does it on 7.5.1.

If this is not it, I will have to go find your example code.

GlenB

--

[Kevin Powick]

On Tuesday, 9 September 2014 23:56:28 UTC-4, GlenB wrote:

PTR=PTR+1
DIM VAR.A(PTR)
VAR.A(PTR)=""
VAR.A(PTR)=My.Dyn.Array

I did try that approach, but it didn't make a difference.  The issue isn't re-dimming anyway.  The tests cases only have one call to the subroutine that DIMs the array.

--

Kevin Powick

[David Knight]

Hi Kevin,

Ran your test routine here & got same results unflashed. [Didn't try flashed, can if you wish]. Weird. Looks like its been there for years going by other posts, so I'm guessing there's a concept being missed...

No idea why. Be interested to see what support say.

d3 v9.2 on W8.1 64 bit

:which cad                                                     

                    System Release Information                 

                    ==========================                 

     D3 Release Version  9.2.0.WINDOWS  rev 14/04/14           

                                                               

     Implementation. . . . . . WINDOWS                         

     Software Serial Number. . 11031373                        

     System ID Number  . . . . xxxxxxxxxx                        

     Release . . . . . . . . . D3                              

     Windows Information . . . Windows;pick0;6.2.9200;;6.2     

                                                               

     Boot Monitor. . . . . . . 9.2.0.001; 14 Apr 2014          

     Boot ABS. . . . . . . . . 9.2.0.A0; 10 Mar 2014           

     Boot ABS Data File. . . . 9.2.0.A0; 10 Mar 2014           

     System Data Files . . . . 9.2.0.D0; 14 Apr 2014           

     FlashBASIC Revision . . . 9.2.F0; 06 Mar 2014             

     SQL Revision. . . . . . . 9.2.S0; 06 Mar 2014             

     ABS Patch Level . . . . . no patches loaded               

[Glen Batchelor]

It's a variable scope bug in the compiler. I verified the DIM error on Linux 7.5.1.

DIM must be in main part of code to not fail with subscript error.

DIM inside the internal sub does not generate a compiler error or run-time error.

A re-DIM, inside the internal sub, does not fix the subscript in memory and it also does not fail.

*popcorn*

[Kevin Powick]

On Wednesday, 10 September 2014 17:55:42 UTC-4, David Knight wrote:

Be interested to see what support say.Thanks for taking the time to test on 7.5.

 

I posted this issue in the Rocket support forum for D3.  Another user confirmed the problem exists on D3 7.5.

Even better, Rocket tech support picked-up on the post and have confirmed that it is indeed a bug in D3, both Windows and Linux versions, from at least 9.0 forward. An action item has been issued.

It's nice to see such quick action from Rocket. This is much different than the old PS/RD/TL days.

--

Kevin Powick

[Kevin Powick]

On Wednesday, 10 September 2014 18:16:14 UTC-4, Kevin Powick wrote:

On Wednesday, 10 September 2014 17:55:42 UTC-4, David Knight wrote:

Be interested to see what support say.Thanks for taking the time to test on 7.5.

 

Sorry about that bit re: 7.5.  It was a cut/paste error.

--

Kevin Powick