This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
RE: stack overflow bug in ofstream::operator<<
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin-developers at cygwin dot com>
- Date: Thu, 30 Jun 2005 13:21:17 +0100
- Subject: RE: stack overflow bug in ofstream::operator<<
----Original Message----
>From: Corinna Vinschen
>Sent: 30 June 2005 12:16
> However, I think I found a way to test if enough space is available on the
> stack. ld stores the size of the maximum available stack in an absolut
> symbol called __size_of_stack_reserve__. This is the default stack size
> for the main thread and threads started with no explicit stacksize. So,
> what I did is to create the following inline function:
>
> inline bool
> check_alloca (size_t size)
> {
> extern unsigned long _size_of_stack_reserve__;
> register char *_curstack __asm__ ("%esp");
> register size_t stacksize = pthread_self ()->attr.stacksize
> ?: (size_t) &_size_of_stack_reserve__;
> return (size_t) ((_curstack - (_tlsbase - stacksize)) / 65536) * 65536
> > size; }
Isn't (_tlsbase - stacksize) just going to be the same thing as _tlsstop?
We have pointers to both ends of the stack in there, don't we? Have I
misunderstood the meaning of StackBase/StackLimit?
> and then something similar to what you proposed in writev:
> Does that sound feasable?
Looks good to me, but I'm still curious why we can't get the *actual*
stack limits rather than trying to deduce them from the initially-allocated
size.
cheers,
DaveK
--
Can't think of a witty .sigline today....