[SOLVED] Stack Overflow without decernable Reason

[jamie]

Now that the range check is fixed, maybe it's time to put the VAR back in the writable arrays?

[MMarie]

As declared the answer is yes.

Is it guess or fact?

Code: Pascal  [Select][+][-]

1.             writeln(sizeof(TInterfaceData));
2.             tmp := ParseASMParam(parameters[0], [prmByte], FInterfaceData); // Causes Stack Overflow, why???
3.             tmp := ConcatByteArrs(tmp, ParseASMParam(parameters[1], [prmAll], FInterfaceData));
4.             out := ConcatByteArrs(out, ConcatByteArrs([OP_LD], tmp));      
5.  

1006633496

That was actually the Problem, thanks! I thought I used my dynamic Integer Array but didn't, now that I've changed it to the dynamic type the size went down to 24 and its executing without a problem. I've got rename my types so that I dont get confused again.

[MMarie]

Now that the range check is fixed, maybe it's time to put the VAR back in the writable arrays?

What do you mean by that?

[jamie]

Looks like you have painted yourself into a corner.

Using stack copies will be sufficient as long as the clump of data does not get too large.

 If you plan on large files you may need to revisit the methods, you are using.

Happy coding.

[PascalDragon]

Using stack copies will be sufficient as long as the clump of data does not get too large.

Dynamic arrays don't take up much stack space (only SizeOf(Pointer) per array). They are solely located on the heap. If one uses static arrays however those are indeed stack hungry...

[jamie]

Quote from: jamie on November 17, 2022, 01:57:43 am
I found that it looks like the compiler is stuffing the incoming array somewhere, maybe the stack? Because it is not pointing to the actual starting array.

The RTL makes an implicit copy when SetLength is called and that is always on the heap.

Quote from: jamie on November 17, 2022, 01:57:43 am
  I did some test, and I can tell you that changing the incoming array size in the function does not change the source of it, so this means the compiler must be making a copy of it.

Dynamic arrays are Copy-on-Resize and with the SetLength the RTL will decouple the passed dynamic array variable from the original.

 Ok, so it makes a heap copy when the length is changed and also decouples itself
from the original array.
 
 So what happens if I am in a loop, I access the incoming array to which currently is the original incoming and later in the loop I resize the array and go back to the start of the loop?
 
  Is there a local stack pointer to the array that gets updated?

  what happens if I was to make a pointer reference to the array before it got renewed ?

[jamie]

Ok, A little knowledge goes a long ways.

After some testing this is what happens and it's something that people should be aware of.

 With a Dynamic Array you can get the pointer to in two ways.

 APointer := @ADynArray; This points to a pointer which points to the actual data.

APointer :=  @ADynArray[0]; This points directly to the start of the data.

 So, if you were to use SetLength on a Dyn Array to a different value than what it already is, it does recreate the array but It also creates a new memory start.

 This means each time you resize the array for example, larger, it needs to rebuild it and most likely will put it elsewhere from where it currently resides.

 So it looks like one needs to be variable careful to ensure you use the address of the pointer and not the address of the actual start of data because once you reset the size differently it may move it elsewhere in memory.

 Thus, the old Indirect addressing...

  I wonder how many bugs are hard to find because of this ?

  Does the compiler spit out a hint indicating address may change if array is resized ,whenever it sees a Pointer:= @ADynArray[?]

 If it does not, maybe it should?

[PascalDragon]

So it looks like one needs to be variable careful to ensure you use the address of the pointer and not the address of the actual start of data because once you reset the size differently it may move it elsewhere in memory.

If you don't use pointers, pass it to formal var or out parameters use or procedures like Move you don't need to concern yourself with this difference.

  Does the compiler spit out a hint indicating address may change if array is resized ,whenever it sees a Pointer:= @ADynArray[?]

 If it does not, maybe it should?

No, because the normal use case for dynamic arrays is not to use pointers.

[jamie]

Quote from: jamie on November 19, 2022, 08:39:05 pm
  Does the compiler spit out a hint indicating address may change if array is resized ,whenever it sees a Pointer:= @ADynArray[?]

 If it does not, maybe it should?

No, because the normal use case for dynamic arrays is not to use pointers.

I understand the concern there however, when you call a remote API there are cases where API wants the start of the actual memory so the only way to do this is to use a @Array[?] for return memory.

 Well at least I know about that and will keep that in mind for now on...
  a Hint would be nice whenever this construct is seen.

Have a good day.