RE: stack overflow bug in ofstream::operator<<

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Tue, 28 Jun 2005, Dave Korn wrote:

> ----Original Message----
> >From: Igor Pechtchanski
> >Sent: 28 June 2005 18:26
>
> > On Tue, 28 Jun 2005, Dave Korn wrote:
> >
> >> ----Original Message----
> >>> From: Igor Pechtchanski
> >>> Sent: 28 June 2005 18:13
> >>
> >>> On Tue, 28 Jun 2005, Dave Korn wrote:
> >>
> >>>>   Hmm.  Can't we tell how much space there is on the stack from the
> >>>> pointers to the stack limits in the NT_TIB (or whatever lives at %fs on
> >>>> 9x), where we get the tls pointers from?
> >>>
> >>> I wonder -- would temporarily installing a signal handler be too much
> >>> overhead?
> >>
> >>   I would have thought it's a lot more work than reading a word from
> >> offset(%fs), subtracting it from the current %esp value, and comparing
> >> it to the size we need....
> >
> > Ok.
> >
> >>> Or is it a thread safety issue (global vars, etc)?
> >>
> >>   Is *what* a thread safety issue?
> >
> > There's a need for communication between a signal handler and the writeev
> > function.
>
>   Well, I was proposing testing how much space was available on the
> stack, so that we never alloca past the bottom of it, and hence don't
> *need* any kind of signal handler.

Yes, and I was simply explaining why I thought installing a signal handler
was a thread safety issue -- I've already agreed with your other point.
The only problem is that some programs may not set the stack boundary
properly, relying instead on page protection to detect stack overflow...
Don't know if there are any in Cygwin.

> >  This is usually done either via global storage (with the
> > obvious drawbacks) or thread-local storage (requiring synchronization,
> > unless a pointer to thread-local data is readily available).
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   Isn't that *exactly* what cygtls is?

Right.  Well, the hope was to keep the common path (via alloca) as fast as
possible, while taking a performance hit when malloc is needed (not enough
stack space).  Checking the stack size every time will introduce equal
overhead on both paths, but I'm not sure we can do better (besides, the
overhead should be pretty small -- a memory read followed by a pointer
comparison).
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT