Structure TEST
struc.w[9999]
EndStructure
Procedure Proc()
Protected a.TEST
Debug "This message should appear in the debugger ..."
Debug "... but it doesn't, because program hangs."
EndProcedure
Proc()
As you can see I declared a structure with an array of 9999 elements. If I now declare a structured variable using TEST inside a structure the program hangs.
Playing around I experienced that this doesn't happen if I decrease the number of elements, change the struc.w to struc.b (or struc.c) or use Global instead of Protected to declare the variable.
So it seems that there is a problem with the size of the memory that has to be allocated for this variable. Is there a limitation for the size a variable can have inside a procedure? Or is this a bug?
Structure TEST
struc.w[ 20000 ]
EndStructure
Procedure Proc()
Protected *a.TEST = AllocateMemory(SizeOf(TEST))
*a\struc[18000] = 12345
Debug *a\struc[18000]
Debug "This message should appear in the debugger ..."
Debug "... but it doesn't, because program hangs."
FreeMemory(*a)
EndProcedure
Proc()
No programming language is perfect. There is not even a single best language.
There are only languages well suited or perhaps poorly suited for particular purposes. Herbert Mayer
That's no bug. The variables in Procedures are allocated on the stack, which isn't unlimited. Fred cant avoid this problem, so you have to realise it in an other way.
> The variables in Procedures are allocated on the stack
Probably a silly question, but ... what is the stack? Already saw this term in the boards concerning ASM Codes but never cared about it, yet. Seems to some kind of memory area ... but where? Is it a special area in the RAM? Is it just used for variables, Pointers, etc.?
Thanks for the answers and the workaround ... think it will do the job, too!
Deeem2031 wrote:That's no bug. The variables in Procedures are allocated on the stack, which isn't unlimited. Fred cant avoid this problem, so you have to realise it in an other way.
As a note, the variables created inside Procedures are allocated on the stack, but not on the main program stack, but on the stack of the procedure.
Each procedure has its own stack.
Anyway, i am not sure whether this problem could be avoided or not
Are you sure about that? If this is true, why save the stack pointer in the ebp register to make room for local variables etc? (Assuming Purebasic does this of course.)
I may look like a mule, but I'm not a complete ass.
Are you sure about that? If this is true, why save the stack pointer in the ebp register to make room for local variables etc? (Assuming Purebasic does this of course.)
I think it is because procedures' stacks pointers are referenced to the main stack one.
I'm with pupil here. I've really not come across anything to suggest that procedures get their own stacks. Certainly a high level language could implement that, but there seems little point when the main thread stack will suffice!
I may look like a mule, but I'm not a complete ass.
I haven't looked on this particular issue, so i can't tell if PB is allocating memory for the static variables for each thread, with threadsafe switch on. However if you're not using threadsafe mode i'm positively sure that all the static varibles just are reserved memoryspots in the data segment of the executable, just like shared and global variables. Just look at the end of the asm source, when compiling with commented switch, and you'll find all global, shared and static variables.
By the way: As my example from above causes a memory overflow in the stack the compiler or debugger should terminate the program with an error message! Wasn't nice to see the program just running and running ... although it did nothing!
Already saw this term in the boards concerning ASM Codes but never cared about it, yet. Seems to some kind of memory area ... but where? Is it a special area in the RAM? Is it just used for variables, Pointers, etc.?
