Stack overflow problem

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Stack overflow problem

Vitaliy Margolen-2
Once more I need your help. It seems that wine is not correct with the way it
sets guard pages for stack. Here is an example that works fine on windows, and
fails on wine. And yes, I do have a program that does something like this:

PDWORD p = TEB.Tib.StackLimit;
*p = 0;

I'm not sure what to do here. It looks like there are several places that we
allocate stack, and both of them set first page (last for stack) as a
PAGE_GUARD. Could that be that this wasn't what we wanted? Since both places
using size of 1. But this looks like sets whole page to be guard page.
--
Best regards,
 Vitaliy



Reply | Threaded
Open this post in threaded view
|

Re: Stack overflow problem

Mike McCormack

Vitaliy Margolen wrote:

> Once more I need your help. It seems that wine is not correct with the way it
> sets guard pages for stack. Here is an example that works fine on windows, and
> fails on wine. And yes, I do have a program that does something like this:
>
> PDWORD p = TEB.Tib.StackLimit;
> *p = 0;
>
> I'm not sure what to do here. It looks like there are several places that we
> allocate stack, and both of them set first page (last for stack) as a
> PAGE_GUARD. Could that be that this wasn't what we wanted? Since both places
> using size of 1. But this looks like sets whole page to be guard page.

Looks like you're investigating a software crippling scheme :)

Wine handles the StackLimit in the wrong way. On Windows, the
ntteb->StackLimit is set to a low value when the program starts, and as
more stack is committed, the kernel increase StackLimit.

On Wine, we never change StackLimit, and it is fixed at the larger of
2Mb or the size the application requests.

The above code results in StackLimit changing.  It's possible your
crippling software is checking that it changes in a "windows like" way.

Mike