flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > error: out of stack space.

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
With the latet vesion dated 12-7-2005 I get "error: out of stack space." when assembling. I tracked the problem to line 47 of SYSTEM.INC (WIN32 directory since I use the windows console version).

Changed to this to make it work for me:

Code:
        add     eax,1000h-10000h
    
Post 13 Jul 2005, 02:58
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 13 Jul 2005, 07:59
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
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.
Post 13 Jul 2005, 11:27
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
I have already changed the default limit to 10000h for all releases but the DOS one (where I've set the limit to 8000h).
Post 13 Jul 2005, 11:45
View user's profile Send private message Visit poster's website Reply with quote
MCD



Joined: 21 Aug 2004
Posts: 604
Location: Germany
MCD
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 Shocked of nested macros/equates or parenthesis.

_________________
MCD - the inevitable return of the Mad Computer Doggy

-||__/
.|+-~
.|| ||
Post 13 Jul 2005, 12:23
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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
Post 13 Jul 2005, 14:38
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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).
Post 13 Jul 2005, 14:45
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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 Smile )
Does forward/reverse cause another kind-of "level"?
Post 13 Jul 2005, 14:52
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
No, this stack usage happens only on each macro call, the internal structure of macro like forward/common blocks doesn't affect it.
Post 13 Jul 2005, 14:59
View user's profile Send private message Visit poster's website Reply with quote
MCD



Joined: 21 Aug 2004
Posts: 604
Location: Germany
MCD
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.
Yep! This is exactly what I was trying to say. I guess revolutions stack overflows don't come from using too deeply nested macros. I rather think it comes from one of the following causes:

1.) Stack related bug in fasm. Ughh, usually, thouse are hard to find Sad
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

-||__/
.|+-~
.|| ||
Post 14 Jul 2005, 10:03
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
3.) misaligned stack?
Anyway, with own handler it shouldn't be very hard to find out
Post 14 Jul 2005, 10:56
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 14 Jul 2005, 13:15
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
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.
Post 15 Jul 2005, 02:23
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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
Post 15 Jul 2005, 08:30
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
Quote:

the limit is now the same on all systems

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 am just wondering what takes up so much stack space?

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
Post 15 Jul 2005, 08:51
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7796
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 15 Jul 2005, 08:56
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
Hehe, just for fun. The smallest possible file that generates stack overflow?
Code:
macro T{}rept 999{macro T{T\}}T    
Post 15 Jul 2005, 09:02
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
Hehe, just for fun. The smallest possible file that generates out of memory?
Code:
macro T{}rept 99{macro T{T}}T    
Post 15 Jul 2005, 09:08
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
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".
Post 15 Jul 2005, 09:11
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17665
Location: In your JS exploiting you and your system
revolution
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.
Post 15 Jul 2005, 09:28
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.