Re: [ATTN MAINTAINER] python

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Mar  4 19:22, Achim Gratz wrote:
> Corinna Vinschen writes:
> > The problem here is how the Windows stack works.  "Stack reserve" is the
> > initial size of the reserved virtual memory space used for the stack of
> > the main thread.  By default that's 2 Megs.
> 
> There were in fact two threads at the point of the SEGV, one in the
> kernel DLL with a very short stack and the other one with a lot of stack
> in compile.c (IÂdon't know which one would be the main thread).
> 
> > However, the stack for the main thread has a problem.  The way a new
> > process is created, the main thread stack is jammed between certain
> > other datastructures, in the address space from 0x30000 and 0x230000.
> > Since the stack is growing top-down, there's nothing a process can do
> > when the reserved stack space is exhausted.  Except generating an
> > exception STATUS_STACK_OVERFLOW.  And then... what?  There's no way to
> > reserve more space below 0x30000 and even *if* it would be possible, it's
> > only a mere 192K.
> 
> I'm just saying that a message like "stack overrun" or something of that
> sort would have told me to go look for the stack size a lot earlier than
> just a segfault.

The problem is, a stack overflow is correctly handled as SEGV from the
POSIX perspective.

But there should have been the right info available.  If you run this
under strace, you get an exception 0xc00000fd or 0xc0000228,
STATUS_STACK_OVERFLOW or STATUS_STACK_OVERFLOW_READ.

Can you check?  If it's an 0xc0000228, there is a chance we're missing
to handle it in our exception handler.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgp1Fc62Cl_Ut.pgp
Description: PGP signature