Index
> Compiler Internals > error: out of stack space.Goto page 1, 2 Next |
| Author |
|
|
Tomasz Grysztar 13 Jul 2005, 07:59
Read this thread: http://board.flatassembler.net/topic.php?t=3770
You should have increased the PE's stack setting aswell, otherwise Win32 won't guarantee such stack size and this newly added code become useless - as it was addedd to guarantee that stack overflow will be detected by fasm before the exception occurs. |
|||
13 Jul 2005, 07:59 |
|
|
revolution 13 Jul 2005, 11:27
Thanks for the tip with the PE's stack.
Many of my programs require more than 16k of stack to properly assemble. Is it possible to make the stack larger by default for the next releases? BTW: I discovered that currently the largest stack I need to get assembly to complete is 049CCh. Perhaps a stack limit of 20k (5000h) or 24k (6000h) would be a good size to choose for standard releases. |
|||
|
13 Jul 2005, 11:27 |
|
|
Tomasz Grysztar 13 Jul 2005, 11:45
I have already changed the default limit to 10000h for all releases but the DOS one (where I've set the limit to 8000h).
|
|||
|
13 Jul 2005, 11:45 |
|
|
MCD 13 Jul 2005, 12:23
I am just wondering what takes up so much stack space? The only thing I can imagine are to deeple nested recursive procedures. What kind of code do you usually assemble with fasm? You must be using thousands
 of nested macros/equates or parenthesis._________________ MCD - the inevitable return of the Mad Computer Doggy -||__/ .|+-~ .|| || |
|||
|
13 Jul 2005, 12:23 |
|
|
vid 13 Jul 2005, 14:38
all saved data are dwords (maybe in qwords in 64bit i don't know), pushing smaller thing causes stack misalign. So divide by four (eight?). Then you usually (in each nest) have to push more things, Divide by 2-3. Then you have macros which use macros which use repeated blocks (forward,reverse etc.) which use instructions which use memory offset which use equation which use constants, (this is quite normal case, nothing extreme), and there you have it. Well, macros are processed before processing instructions etc, but i wanted to demonstrate...
This is just my opinion, maybe it's other way and maybe you are just writing too nested code, who knows... In assembly you should code "linear" until stack-ed code is really required. Last edited by vid on 13 Jul 2005, 14:45; edited 1 time in total |
|||
|
13 Jul 2005, 14:38 |
|
|
Tomasz Grysztar 13 Jul 2005, 14:45
The assembly-time nested structures don't use stack for this purpose, they use other kind of stack in the so-called additional memory block. The only things in fasm that use the stack extensively are the nested macroinstructions, and each level eats about dozen of double words in this case (the repeated blocks, however, don't increase it).
|
|||
|
13 Jul 2005, 14:45 |
|
|
vid 13 Jul 2005, 14:52
so 10000h/(12*4) gives (roughly, taking also other things in mind) 1200 levels. I think this wouldn't be reached in any normal code. (until you create some Prolog syntax with new macrofeatures
 )
Does forward/reverse cause another kind-of "level"? |
|||
|
13 Jul 2005, 14:52 |
|
|
Tomasz Grysztar 13 Jul 2005, 14:59
No, this stack usage happens only on each macro call, the internal structure of macro like forward/common blocks doesn't affect it.
|
|||
|
13 Jul 2005, 14:59 |
|
|
MCD 14 Jul 2005, 10:03
vid wrote: so 10000h/(12*4) gives (roughly, taking also other things in mind) 1200 levels. I think this wouldn't be reached in any normal code. 1.) Stack related bug in fasm. Ughh, usually, thouse are hard to find 
2.) May be another Win32 stack allocation bug. Hopefully not, 'cause this would mean another dump workaround. _________________ MCD - the inevitable return of the Mad Computer Doggy -||__/ .|+-~ .|| || |
|||
|
14 Jul 2005, 10:03 |
|
|
vid 14 Jul 2005, 10:56
3.) misaligned stack?
Anyway, with own handler it shouldn't be very hard to find out |
|||
|
14 Jul 2005, 10:56 |
|
|
Tomasz Grysztar 14 Jul 2005, 13:15
MCD wrote: 1.) Stack related bug in fasm. Ughh, usually, thouse are hard to find That's quite impossible, since the whole assembly wouldn't work at all if stack was keeping some bad values at any point - the stack contains mainly return addresses for all procedure calls (and other pointers), so that the whole process works correctly means that the stack is OK. Anyway, I have underestimated the usage of stack by my macro handler - after looking at source I see it can be even over 20 double words per one macro nesting. And several double words per include nesting, too. And note that revolution had problem with stack smaller than 16K, not the current 64K, for which the vid's estimations apply. |
|||
|
14 Jul 2005, 13:15 |
|
|
revolution 15 Jul 2005, 02:23
It is easy to create a stack overflow:
Code: macro TestData {} rept 776 { macro TestData \{ TestData db 'testabc',0 \} } TestData Each time a string is added to the TestData macro the stack usage increases. Note: For the above code 776 will create a stack overflow in the WIN32 console version using Windows XP SP2. 775 will compile okay. I have not tested other platform versions so perhaps the 776 limit is different on your system. |
|||
|
15 Jul 2005, 02:23 |
|
|
Tomasz Grysztar 15 Jul 2005, 08:30
No, the limit is now the same on all systems, since it's now hardcoded by fasm - just to be able to detect overflows.
Last edited by Tomasz Grysztar on 15 Jul 2005, 08:56; edited 2 times in total |
|||
|
15 Jul 2005, 08:30 |
|
|
revolution 15 Jul 2005, 08:51
Quote:
Except for DOS where the limit is only 32k. But I was more trying to say that the value 776 might be plus/minus 1 or 2 for Linux, WIN IDE etc. Although I expect if it was changed to 1000 then all systems would report a stack overflow. Quote:
I use macros to define various bits of data thoughout the assembly files and then combine each piece into one group in the output file. example: Code: .add_a_string ;<-- this is a macro string_label: db "Stuff",0 ;<-- the string to combine wth the other strings. .back_to_code ;<-- and another macro ... ;some code .add_a_string ;<-- this is the macro again string_label2: db "Other Stuff",0 ;<-- the string to combine wth the other strings. .back_to_code ;<-- and the other macro again ... ;some more code .place_strings_here ;<-- the macro that dumps all the strings in one common place Last edited by revolution on 15 Jul 2005, 09:01; edited 1 time in total |
|||
|
15 Jul 2005, 08:51 |
|
|
Tomasz Grysztar 15 Jul 2005, 08:56
It's better to use some non-nesting variant of such tricks, if you need them - like the global macros. Or use the EQU - since the definitions of symbolic constants are unrolled at define time, no nesting happens there.
|
|||
|
15 Jul 2005, 08:56 |
|
|
revolution 15 Jul 2005, 09:02
Hehe, just for fun. The smallest possible file that generates stack overflow?
Code: macro T{}rept 999{macro T{T\}}T |
|||
|
15 Jul 2005, 09:02 |
|
|
revolution 15 Jul 2005, 09:08
Hehe, just for fun. The smallest possible file that generates out of memory?
Code: macro T{}rept 99{macro T{T}}T |
|||
|
15 Jul 2005, 09:08 |
|
|
revolution 15 Jul 2005, 09:11
Hehe, just for fun. The smallest possible file that generates application error?
Code: macro T{}rept 1{macro T{T}}T Quote: The instruction as "0x00401c15" referenced memory at "0x1033b000". The memory could not be "written". |
|||
|
15 Jul 2005, 09:11 |
|
|
revolution 15 Jul 2005, 09:28
Quote: Or use the EQU - since the definitions of symbolic constants are unrolled at define time, no nesting happens there. I will try this option. |
|||
|
15 Jul 2005, 09:28 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|