Page 1 of 2
[PB4] Array in Structure
Posted: Sun May 28, 2006 10:37 am
by Christian
Hi there!
I've got a problem concerning this code:
Code: Select all
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?
Thanks in advance!
Regards
Christian
Posted: Sun May 28, 2006 12:50 pm
by Flype
yes you're right, the limit seems to be ~12240 bytes.
there shouldn't be limits.
as a temporary workaround you can allocate yourself the memory needed for the structure.
Code: Select all
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()
Posted: Sun May 28, 2006 6:37 pm
by Deeem2031
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.
Posted: Mon May 29, 2006 9:16 am
by Christian
> 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!
regards,
Christian
Posted: Mon May 29, 2006 4:30 pm
by Deeem2031
Posted: Mon May 29, 2006 4:47 pm
by josku_x
Thanks Deeem for the link, that's going to help me for sure.
Posted: Mon May 29, 2006 5:36 pm
by Psychophanta
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

Posted: Mon May 29, 2006 6:34 pm
by srod
Each procedure has its own stack.
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.)
Posted: Mon May 29, 2006 6:42 pm
by Pupil
I'm pretty sure that every procedure doesn't have it's own stack. Only threads and processes get their own stacks.
Posted: Mon May 29, 2006 6:45 pm
by Psychophanta
srod wrote:Each procedure has its own stack.
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.
Posted: Mon May 29, 2006 6:48 pm
by srod
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!
Posted: Mon May 29, 2006 6:50 pm
by Psychophanta
Well, you are making doubt me, but at least for Static vars, there must be a stack per procedure:
http://www.purebasic.fr/english/viewtopic.php?t=21950
Posted: Mon May 29, 2006 6:57 pm
by srod
I always assumed that statics were placed in the program's heap somewhere. Must admit that I haven't checked it out - have had no need!

Posted: Mon May 29, 2006 6:59 pm
by Pupil
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.
Posted: Tue May 30, 2006 9:19 am
by Christian
Thanks for the link Deem!
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!
Regards,
Christian