This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


----Original Message----
>From: Igor Pechtchanski
>Sent: 28 June 2005 19:10

> 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.

  Oh, gotcha, sorry!

> 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.

  I don't think that's even possible to happen, is it?  Certainly on NT the
stack details are entered into the TIB at thread creation time.  Page
protection is indeed used as part of the stack control mechanism; it's how
the OS knows to grow the stack by committing more pages into the lower end
of the reserved-but-not-committed space below the
lowest-so-far-value-of-esp, and it's why you have to probe the stack every
4k when you're building a large stack frame.  If those variables weren't set
up correctly, I don't know how the OS would know when it had reached the
bottom of the allocation and had to report a stack overflow instead of
continuing to grow it.

>>>  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).

  Ok, I'm following you up to this point ...

>  Checking the stack size every time will introduce equal
> overhead on both paths, 

  ... but now you've lost me.  How does checking the stack space make the
alloca path take as long as the malloc path?

> but I'm not sure we can do better (besides, the
> overhead should be pretty small -- a memory read followed by a pointer
> comparison).

  Umm, this is all completely lost in the noise next to the difference in
execution times between malloc and alloca isn't it?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]