Handmade Hero»Forums»Code
50 posts
Memory stack not affected with the -F4194304 optio
Edited by itzjac on
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?!
Mārtiņš Možeiko
2235 posts / 1 project
Memory stack not affected with the -F4194304 optio
Edited by Mārtiņš Možeiko on
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
50 posts
Memory stack not affected with the -F4194304 optio
Edited by itzjac on
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.
50 posts
Memory stack not affected with the -F4194304 optio
Edited by itzjac on
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. :(
Mārtiņš Možeiko
2235 posts / 1 project
Memory stack not affected with the -F4194304 optio
Are you sure it is allocation that crashes not some stack corruption?
_chkstk typically asserts if stack is corrupted or overflows.
50 posts
Memory stack not affected with the -F4194304 optio
Edited by itzjac on
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;
}
50 posts
Memory stack not affected with the -F4194304 optio
Edited by itzjac on
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?
Mārtiņš Možeiko
2235 posts / 1 project
Memory stack not affected with the -F4194304 optio
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).
50 posts
Memory stack not affected with the -F4194304 optio
That's the reason! Thanks!