Handmade Hero » Forums » Code » Memory stack not affected with the -F4194304 optio
itzjac
10 posts
#4387 Memory stack not affected with the -F4194304 optio
1 year, 8 months ago Edited by itzjac on July 28, 2015, 8:08 p.m.

Hi,

Sorry to join so late to the party. I have a very basic question regarding
day 005 and how to manipulate stack size.

I have tried using both x86 & x64 with the command line

cl -F4194304 -FC -Zi ..\code\Source.cpp user32.lib gdi32.lib

And the array

int bigdata[1024*1024] = {}; // 1Mb

And I still get the stack overflow crash, any idea what I am doing wrong?

All the best for this project, and Mr. Muratori I also hated school but I finally
found my true master!
Thank you for all your effort and sharing your knowledge.

[EDIT] does the forum contain a search filed? where is it?!
mmozeiko
Mārtiņš Možeiko
1247 posts
1 project
#4388 Memory stack not affected with the -F4194304 optio
1 year, 8 months ago Edited by Mārtiņš Možeiko on July 28, 2015, 9:35 p.m.

Try /STACK linker argument:
1
cl.exe -FC -Zi ..Source.cpp uer32.lib gdi32.lib -LINK -STACK:4194304


Search is a hidden feature in this forum: https://forums.handmadehero.org/index.php/forum/search
itzjac
10 posts
#4400 Memory stack not affected with the -F4194304 optio
1 year, 8 months ago Edited by itzjac on July 29, 2015, 6:03 p.m.

Hi!

Thank you for the hint. Still doesn't work.

I tried also executing the commands from an admin console, just in case,
but neither the link nor the -F option worked.

BTW the linker only worked with lower case

1
cl   -FC -Zi ..\code\Source.cpp user32.lib gdi32.lib /link /STACK:4194304


Also I can confirm that the linker is including this information


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40302 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

Source.cpp
Microsoft (R) Incremental Linker Version 12.00.40302.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:Source.exe
/debug
-STACK:4194304
Source.obj
user32.lib
gdi32.lib


The interesting part is that callstack in the crash shows this
1
2
 	Win32Project1.exe!_chkstk() Line 99	Unknown
>	Win32Project1.exe!__tmainCRTStartup() Line 618	C

I suspect the __chkstk() is some defense mechanism still enabled in windows.
If I don't specify the stack size, the crash is clearly an Stack overflow.
itzjac
10 posts
#4401 Memory stack not affected with the -F4194304 optio
1 year, 8 months ago Edited by itzjac on July 29, 2015, 6:26 p.m.

Alright I found the problem, Debug builds.

How come your builds are by default in release mode?
Switching to release the program runs ok.

Apparently including the option

1
/GS-


Would be the cure, but I still get the crash in debug mode and disabling security check. :(
mmozeiko
Mārtiņš Možeiko
1247 posts
1 project
#4402 Memory stack not affected with the -F4194304 optio
1 year, 8 months ago

Are you sure it is allocation that crashes not some stack corruption?
_chkstk typically asserts if stack is corrupted or overflows.
itzjac
10 posts
#4404 Memory stack not affected with the -F4194304 optio
1 year, 8 months ago Edited by itzjac on July 29, 2015, 7:37 p.m.

I don't know how would I corrupt my stack by entering WinMain, the big
array is declared right in the beginning.
But again, by just switching the compiling mode to Release it works as a charm.

But I really want to know what's going on.

Even if I remove all the code and leave this, I still have the same behavior


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
int CALLBACK WinMain(
	HINSTANCE Instance,
	HINSTANCE PrevInstance,
	LPSTR     CommandLine,
	int       Showcode
	)
{
	int bigdata[1024*1024] = {}; // 1Mb


	return 0;
}
itzjac
10 posts
#4405 Memory stack not affected with the -F4194304 optio
1 year, 8 months ago Edited by itzjac on July 29, 2015, 7:50 p.m.

I've got it.


1
cl  -Ox -F4194304 -FC -Zi  ..\code\Source.cpp user32.lib gdi32.lib 


With such optimizer option it runs, I can use also -O1, -O2 and will still work.
Seems these optimization levels somehow strip out the checks.

On the other hand the options -Os, -Ot will again produce the crash.

Anyone has a good explanation about it?
mmozeiko
Mārtiņš Možeiko
1247 posts
1 project
#4406 Memory stack not affected with the -F4194304 optio
1 year, 8 months ago

Oh, I see the problem now.

First of all - when such program is compiled with optimizations turned on (release "config") the compiler will simply throw away this variable. Nobody is using it so there is no need for it. That's why everything works with -O1/2/x.

-Os/-Ot arguments don't turn on optimizations. They only control what -Ox will optimize for - size or speed.

And why it crashes - because you are not allocating only 1 MB on stack. You are allocating 4 MB. 1024*1024 of integer elements means 4*1024*1024 bytes.

So you need to increase stack size. Because 4194304 is exactly 4MB, but compiler needs a bit more - at least for storing return address and frame pointer setup (and any temporary pushes on stack if present).
itzjac
10 posts
#4407 Memory stack not affected with the -F4194304 optio
1 year, 8 months ago

That's the reason! Thanks!