Going a little mad trying to figure out a problem with $Debug

[hanness]

I'm building a framework for some new code in one of my existing programs. I wanted to use debug to take a look at the values in several variables, including a few arrays.

In this section of code I use an array called ParSize using LONG as the type. In a completely different section of code I have another array called PartitionSize as a type of STRING.

In using debug, I accidentally started monitoring the PartitionSize array but was really after ParSize.

Now here is the weird part:

If I run the program normally, I have no problems. But when I set a break point and step through the code line by line using F7, I keep getting a subscript out of range error. It happens only if I am monitoring that PartitionSize array. Also, nowhere in the code that is being executed is that variable ever touched (as far as I can tell) other that the original DIM statement near the start of my program.

Is there any way that someone could provide me ideas on the types of things to look for to figure out what is happening?

[FellippeHeitor]

If you can, please share the code and the exact steps to reproduce the issue.

[FellippeHeitor]

Also, which build?

[hanness]

Thank you. I appreciate you taking an interest in this.

Running build 1e67962 on Windows 11.

I'll attach the code as a ZIP file! Fortunately, because I'm focusing on a new section of code I put in some test code to simply bypass huge chunks of code and take me to the portion that is my current focus so really very little code is run at this point.

The code has to run elevated, so to make that work with QB64, I have run QB64 as admin.

Here are the steps to repro:

Set a breakpoint on line 3883. This line reads: If Temp$ = "H" Then

Run the program (F5). Make sure that QB64 is being run elevated.

On your system, you may get a warning that the Windows ADK is not installed (not sure if you will or if I am bypassing that section). The program requires this for some operations but for this test it won't matter. Just continue if you do get such a warning.

You will get just a few questions before the breakpoint. Here are the answers and responses to supply:


Q: For this project, should we exclude the autounattend.xml answer file if it exists?
A: Y

Q: Do you want to inject an EI.CFG file into your final image?
A: Y

Q: Single, Multiple, or Help: ?
A: M

You are now at the breakpoint. Press F7 a few times. You only need to go as far as the line of code that reads

TotalPartitions = 0

Go a line or two past that and note that all is well.

Stop the program.

Set a watch for "PartitionSize" specifying indices 1-2.

Perform the exact same steps as above. As soon as you hit the "TotalPartition = 0" you should get a subscript out of range.

  [ You are not allowed to view this attachment ]  

[hanness]

Spelling error in my post. The variable to watch is PartitionSize.

[hanness]

Okay, hold off looking at this. I think I found my problem. Just wanted to shout before I wasted more of your time. I should have confirmation in a couple minutes.

[hanness]

I was wrong. Same problem. I had found another location in my code where I mixed up thse two variables. Also had a Source$ and a Source$ array so I changed the array to a different name. Neither made any difference, however. Just can't wrap my head around this one.

[Pete]

Try putting...

ReDim PartitionSize(4) As String

right after...

BeginProgram:

In other words...

BeginProgram:
ReDim PartitionSize(4) As String

Probably no need to remove the former location, just have both of them for now and see if it passes debug mode.

Pete

[hanness]

Pete, that actually made it worse. It gives me a subscript out of range right on the line where the breakpoint was set.

That is actually a recurring theme now. If I do not set a breakpoint, no error. The code runs fine.

If I set a breakpoint where I noted in my repro, then it fails a few lines later at the line that reads "TotalPartitions = 0 ".

If I set a breakpoint AFTER that line, the code will run fine up until that breakpoint but immediately fail when it hits that breakpoint.

So it seems to me that the line "TotalPartitions = 0 " is a key to this, BUT, it only causes a subscript out of range when in debug mode by stepping to it with F7 or by setting a breakpoint on or after that line.

[hanness]

Another data point. Whether this helps or not, I don't know.

So, the line where it is failing, that reads "TotalPartitions = 0"...

If I comment that line out it will fail on the very next line. So clearly, it is not precisely that line that causes the issue. However, that happens to be the first thing that is executed after jumping to the label called "Boot_MultipleMode" which is more than 1,000 from the point of origin. I wouldn't think that should matter, but thought I would mention it.

Also, I did consider that having an underscore in the label name might be a problem so I changed that, but it makes no difference.

[hanness]

!!! I found it !!!!

So the problem is that I have a number of variables for which I perform a ReDim but I never have an original DIM statement.

In my code, this works just fine, but apparently Debug does not like this.

I simply placed a "Dim PartitionSize(0) as String" near the start of my code with all the other DIM statements and the problem is solved.

The problem is that I think I do this with a bunch of variables so I need to look at every single ReDim in my 13,000 lines.

So, the logical question: Should what I am doing (ReDim without a preceeding Dim) ne valid or not?

[Pete]

That's a good find, and I think it should be fixed in the debug version. In QB64 there has never been a need to use DIM with REDIM. I almost exclusively just use REDIM in many apps. It felt like debug wasn't recognizing the array had already been diminsioned. That's why I suggested putting it at the start.

Pete

[FellippeHeitor]

!!! I found it !!!!

So the problem is that I have a number of variables for which I perform a ReDim but I never have an original DIM statement.

In my code, this works just fine, but apparently Debug does not like this.

I simply placed a "Dim PartitionSize(0) as String" near the start of my code with all the other DIM statements and the problem is solved.

The problem is that I think I do this with a bunch of variables so I need to look at every single ReDim in my 13,000 lines.

So, the logical question: Should what I am doing (ReDim without a preceeding Dim) ne valid or not?

Glad you managed to pin it down to that. There's absolutely no problem use solely ReDim, but bear in mind that, unless there's a '$DYNAMIC meta command in your program (which makes all arrays dynamic and resizable), there's a difference between DIM and REDIM. With DIM, your array is static, so you cannot REDIM it later. With REDIM, you create a dynamic array from the get go.

$Debug mode stores the address in memory of all variables and arrays. Now that you've pointed it out, I'll try to find out if a REDIM could be moving the array in memory just as well, which could be causing the issue.

The fact that no line mentioning the array was ever run, but the error was still coming up, is because you'd added the array to your Watch List, and the debugger module needs to try to read it with every cycle, in order to update the Watch Panel of variable values. That means it's also checking UBound and LBound internally, and that's where the "Subscript Out Of Range" error is coming from.

Thanks for reporting, I'll see into it.

[FellippeHeitor]

@hanness @Pete ✨ New dev build ✨ now available with the issue hopefully fixed. Please let me know how your tests go. ✅

[hanness]

Fellippe, that did indeed fix it! I can't believe how quickly you fixed that.

This is fantastic.  Thank you so much. Can't believe how fun this is making programming for a novice like me.