Reserved and commited memory

[Luc MAIGNAN]

I declare a local variable of 12 Ko in a function. I link with a stack
reserved memory of 24 Ko and a stack committed memory of 4 Ko. My program
makes a fault.
IF I link with a stack committed memory of 24 Ko, all is ok.
Why coundl'nt the system commit the reserved memory when necessary ?
Thank you for any help
Regards
Luc MAIGNAN
lmai...@natsys.fr

[Jeroen ter Hofstede]

Luc,

You may need support from the compiler here, generating so-called "stack
probes." Windows has one 4kb guard page at the end of the stack. If this
page is used it generates an exception. Windows then will commit this page
and make the next page the guard page.
This all works very nicely until you use stackspace in chunks larger than a
4kb page - in that case a reference to the stack may skip the guard page and
access another uncommited stack page, causing a fault.
Compilers often are able to generate special code at the entry of a function
which will ensure that all necessary stack is available even if your locals
are larger than 4kb, by having multiple stack-accesses no more than 4kb
apart. Consult your compiler documentation for "stack probe".

Regards,
Jeroen ter Hofstede, J.ter.H...@pluriform.nl

Luc MAIGNAN wrote in message <4n1V1.4$nV.3...@France.EU.net>...

[Markus Becker]

Luc MAIGNAN wrote:
>
> I declare a local variable of 12 Ko in a function. I link with a stack
> reserved memory of 24 Ko and a stack committed memory of 4 Ko. My program
> makes a fault.
> IF I link with a stack committed memory of 24 Ko, all is ok.
> Why coundl'nt the system commit the reserved memory when necessary ?

Because (just a guess) it allocates (commits) 4 KB, sees that there
still
ins't enough room for your 12 KB object and gives up.
If you have a commit of 12 KB then the allocated space is enough.

Markus

[Kim Liu]

This is an interesting topic you brought up here. I did some research myself
and I suspect that the explanation given by Jeroen is not totally correct.

Usually, the compiler will automatically generate the necessary
stack-probing code for function calls that need it. The /Gs switch in VC++
is not necessary unless you are doing something very advanced.

So exactly which compiler are you using? I don't understand why you want to
reserve a stack size of only 24K. Reserving 1MB (the default) is not really
that bad. It doesn't use 1MB of memory (not even 1MB in the pagefile). It
merely reserves 1MB in your virtual address space and you have 2GB of that
to spare.

Anyway, one problem of your case is that you can't really commit 24KB of
stack space out of the 24KB of reserved stack space. The last reserved page
cannot be commited (at least on NT). So you can have at most 20KB. I don't
know exactly what's wrong with your program but is it possible that you are
actually using more than 20KB of memory (your 12KB local variable plus
everything else you didn't notice)? So on a normally-behaving system, you
will run out of stack memory at 20KB. But if you force the compiler to
commit all 24KB (God knows whether this is indeed possible), then you will
have enough memory to satisfy your 20KB+ need. My suggestion for debugging
is to reserve something like 32KB (and don't change the default amount of
commit memory) and see if it works.

The book Advanced Windows by Jeffrey Richter has a good discussion of this
subject.

-Kim

Jeroen ter Hofstede wrote in message <702bki$oki$1...@news.Eindhoven.NL.net>...

>Luc,
>
>You may need support from the compiler here, generating so-called "stack
>probes." Windows has one 4kb guard page at the end of the stack. If this
>page is used it generates an exception. Windows then will commit this page
>and make the next page the guard page.
>This all works very nicely until you use stackspace in chunks larger than a
>4kb page - in that case a reference to the stack may skip the guard page
and
>access another uncommited stack page, causing a fault.
>Compilers often are able to generate special code at the entry of a
function
>which will ensure that all necessary stack is available even if your locals
>are larger than 4kb, by having multiple stack-accesses no more than 4kb
>apart. Consult your compiler documentation for "stack probe".
>
>Regards,
>Jeroen ter Hofstede, J.ter.H...@pluriform.nl
>
>Luc MAIGNAN wrote in message <4n1V1.4$nV.3...@France.EU.net>...

>>I declare a local variable of 12 Ko in a function. I link with a stack
>>reserved memory of 24 Ko and a stack committed memory of 4 Ko. My program
>>makes a fault.
>>IF I link with a stack committed memory of 24 Ko, all is ok.
>>Why coundl'nt the system commit the reserved memory when necessary ?

[Jeroen ter Hofstede]

Hi Kim,

>Anyway, one problem of your case is that you can't really commit 24KB of
>stack space out of the 24KB of reserved stack space. The last reserved page
>cannot be commited (at least on NT). So you can have at most 20KB. I don't

Due to some inexplainable crashes which might be stack-related I have done
some tests a couple of weeks ago. It appears that you *can* commit the
entire stack on NT - however in that case you don't have a guard page left.
Overrunning your stack will lead NT to abort your program silently; no
diagnostic of any kind is provided. So, while it is possible (I think), it
surely isn't wise.

>will run out of stack memory at 20KB. But if you force the compiler to
>commit all 24KB (God knows whether this is indeed possible), then you will

That's too much honor - I am a mere mortal ;-)

Regards,
Jeroen.

[Kim Liu]

> It appears that you *can* commit the entire stack on NT

So maybe the OS (NT) does not enforce that the last page should not be
commited. That makes sense. Maybe it's the compiler that should enforce
this. It wasn't clear from Richter's book. So how exactly did you manage to
commit the last page? Did you simply specify the same size for reserve and
commit memory in the linker switch? And the compiler doesn't give you a
warning or something?

-Kim