redim inside function causing memory issue?

[mmbcastle]

Working on Win 10, 32 bit. FBC 1.07.2

I'm testing the conversion of a lot of old legacy QB code to FB. I'm working on the libraries now. I'm trying to find the path where I have to modify the least amount of the old code in this first pass as possible. It's been looking very promising, but I ran into a run time error I think is related to memory management.

I am testing a full screen input routine now (like a window form, enter multiple fields, hit F10 to accept screen contents). It reads a screen definition from a file. This includes the background text and definitions of fields on the screen. It creates a number of temporary arrays to manage things. When running the test program, the first pass through it works perfectly. However, when the program loops back to show the full screen input again, Windows gives a "SCRNFULL.exe has stopped responding...." window. When I tell it to debug, Visual Studio reports this error...

Unhandled exception at 0x0040CD1F in SCRNFULL.exe: 0xC0000005: Access violation reading location 0x00000010.

Originally, I had all the internal arrays set up as REDIMs. I've also tested with DIMs and get the same result.

The function is defined as....
public SUB SCREEN.INPUT(SCN.NAME$,HELP$,FLNUM%,B$()) STATIC

B$() is the data to populate the fields. I am dumping it on return to make sure the data is coming back out of the first call ok and it is.

FLNUM% is just a number the function can use to open a file (no freefile command in 1987 when this was first written). I've tried using freefile internally in case FB treats file number/pointers as more special than QB did.

[fxm]

If the arrays passed to the function are well dynamic (declared in the main code with for example REDIM), there is no problem to resize these arrays from inside the function on condition only of respecting the number of dimensions which was set at the level of the first declaration in the main code.

Without a code where the observed fault occurs, we have trouble being able to help you with your debugging.

[Julcar]

You could request an upperbound, and avoid accessing an index beyond that number

[MrSwiss]

redim inside function causing memory issue?

Yes it can and does, with all the previous/current FBC versions, on statically sized arrays.
Okay only, for dynamic sized arrays. (currently: programmers responsibility)
In case you're using it on a static-sized array you're getting a program-crash!

However, there is a upcoming fix for that, in FBC 1.08.0 (current development stage = OK!).
For the first time ever, there will be a chance to test the array inside procedures, for static or dynamic sizing.
This then allowes to guard against these crashes "in code".
(path: [FBC]/inc/fbc-int/; include-file: array.bi; namespace: "FBC")

[Josep Roca]

Static arrays can also cause problems when used, e.g., inside a class. I did write an application called FBPiano that used a class (CPiano) with two static arrays in it, and I had to change them to global arrays.

I kept the original and, in the changed version, I put the following remark:

' // Note: Declared as global because declaring them as instance variables of the class
' // causes strange memory problems, like the m_Octave variable being sometimes reset to 0
' // for no apparent reason.
DIM SHARED m_pk(127) AS CPIANO_KEY ' // Static key data array
DIM SHARED m_hRgn(127) AS HRGN ' // Region array

[fxm]

Static arrays can also cause problems when used, e.g., inside a class. I did write an application called FBPiano that used a class (CPiano) with two static arrays in it, and I had to change them to global arrays.

This possible problem should be explored, but rather on a simple example.

[speedfixer]

Whenever an array is REDIMed, however it is being referenced, the reference is probably now pointing at the wrong place.
If you explicitly declare a pointer to that array (with proper scope), then reassign it after every redim, you can't go wrong.

This has always worked for me (after fxm pointed out that need to me - thank you).

david

[mmbcastle]

Sorry I hadn't seen all the replies. It didn't auto-subscribe me. Thank you all so much!

The arrays in question are only referenced inside the function. The array that is passed to the function may be static or dynamic depending on the application, but is never resized after being initially defined (either in the library or the calling application).

I will try a test where I initially define the arrays as global inside the library (rather than inside the function) and see if that helps. Sounds promising from what I see in the replies.

[fxm]

In FB:
- to declare a temporary array inside a procedure, you must use the 'DIM' keyword,
- to declare a permanent array inside a procedure, the keyword 'STATIC' must be used instead.

[MrSwiss]

Different array declaring ways and results explained:

Code: Select all

Dim As Long     lb, ub          ' for dynamic array sizing

' creating dynamic arrays
Dim As String   sa()            ' dynamic, undimensioned, unsized
Dim As String   sa(Any)         ' dynamic, 1 dimension, unsized
Dim As String   sa(lb To ub)    ' dynamic, 1 dimension, sized by variables (user defined BASE)
ReDim As String sa(1 To 10)     ' dynamic, 1 dimension, sized (10 elements) BASE1
ReDim As String sa(0 To 9)      ' dynamic, 1 dimension, sized (10 elements) BASE0
ReDim As String sa(9)           ' identical to above

' by contrast static arrays
Dim As String   sa(1 To 10)     ' static, 1 dimension, sized (10 elements) BASE1
Dim As String   sa(0 To 9)      ' static, 1 dimension, sized (10 elements) BASE0
Dim As String   sa(9)           ' identical to above

[mmbcastle]

Thanks for all the help. This particular hurdle has now been crossed.

I ended up changing all the REDIMs to DIMs and dropping the ERASE statements and that resolved the issue.

I thought I'd tried that already, but I guess not.