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?!
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?!
Edited by itzjac
on
Try /STACK linker argument:
Search is a hidden feature in this forum: https://forums.handmadehero.org/index.php/forum/search
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
Edited by Mārtiņš Možeiko
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
Also I can confirm that the linker is including this information
The interesting part is that callstack in the crash shows this
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.
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.
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
Would be the cure, but I still get the crash in debug mode and disabling security check. :(
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. :(
Edited by itzjac
on
Are you sure it is allocation that crashes not some stack corruption?
_chkstk typically asserts if stack is corrupted or overflows.
_chkstk typically asserts if stack is corrupted or overflows.
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
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;
}
|
Edited by itzjac
on
I've got it.
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?
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?
Edited by itzjac
on
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).
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).