need help checking for stack overflow in Win32

[Toby Dickenson]

Robin Becker <robin at jessikat.demon.co.uk> wrote:

>In article <7j1pcc$256$1 at m2.c2.telstra-mm.net.au>, Mark Hammond
><MHammond at skippinet.com.au> writes
>>Actually, I was about to post this yesterday, and to prove my point I wrote:
>>
>>def die():
>>    die()
>>
>>Expecting to see the crash.  I was then going to go into a rant about how
>>win32api.Apply would actually let you catch this (and any other Win32)
>>exception as a temporary solution.
>>
>>But it worked correctly - ie, Python raised a RuntimeError: Max Recursion.
>>
>...
>I just tried this with my bog standard 1.5.2 under win95 osr2 and it
>faults to the system. Strange :)

It could be that Mark did actually exceed the 1MB stack, but windows was able to
extend it since the relevent bit of his process's address space had not been
reserved.

Mark also wrote:

>A better mechanism would be to use Win32 exception handlers.  Then you dont
>need artificial recursion checks at all - leave it to the OS.  However, it
>isnt clear to me where this exception handler should be placed, nor indeed
>if setting up a Win32 exception handler inside the VM would have a
>significant performance hit.  A plus would be we could also catch Access
>Violations (Im not sure what we would do with them - but a traceback would
>be nicer than Dr Watson when dealing with buggy extensions!)

Getting this to work could be tricky. The win32 exception could be generated
when the VM or an extension was in an inconsistant state, and it may not be
possible to continue processing after swallowing the RuntimeError. If we don't
need to do that, then what is wrong with Dr Watson?

>Thomas' solution is simple, and requires either a simple source file change,
>or using the MSVC GUI to adjust the stack size.

I don't think adjusting the stack size is a viable option. Python is used in
some places where it is not in control of this parameter; in-process com servers
being the obvious example.



Toby Dickenson