[ODE] Stack overflow

[Marco Grubert]

> The /STACK linker option basically tells Windows that it should puke when
> the application tries to use more than N bytes of stack.  This problem is
> easily solved: use a spectacularly large value for the /STACK linker
> option.  If 800MB doesn't sound like enough, use 800GB.  They'll behave
> the same way at run-time, at least until machines with more than 800MB
> become common.

That's where I am having doubts. Is there really no trade-off for specifying
a larger amount? Like more background management going on?

> The point is to choose a stack size so ridiculously large that if the
> memory demands ever actually get that big, there won't be anything to be
> done about it anyhow.

Still you don't want to crash the app. I have just finished my
implementation for a graceful exit and will post that next week. The result
right now is that some of the objects get updated, then the stack overflow
occurs leaving the rest of the objects unaffected. Looks a little funny :-P
Returning all objects to the previous state is more elegant but then you
will never get anywhere. So what would be a good solution to recover from
this situation ?

> I haven't looked at XP details, but I have a hunch that this on-the-fly
> stack adjustment is subject to a ceiling set by the /STACK linker option.
> That is how Win2k works.  Setting that ceiling to HUGE_VAL seems to me
> like a perfectly acceptable solution.

No it's not. Up until Win XP you could not alter the ceiling value during
runtime, with Win XP you can. Assuming that there is a reason for not giving
the whole 2 GB of available space to ODE, I guess the best way is to start
with a moderate ceiling, catch Stack_overflows and adjust the ceiling as
necessary.

Could anyone please find out how the Windows Kernel handles large stack
reservations, i.e. if it's okay to reserve the 2Gigs ?

- Marco Grubert