This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: stack overflow bug in ofstream::operator<<
On Tue, Jun 28, 2005 at 01:12:41PM -0400, Igor Pechtchanski wrote:
>On Tue, 28 Jun 2005, Dave Korn wrote:
>
>> ----Original Message----
>> >From: Corinna Vinschen
>> >Sent: 28 June 2005 16:57
>>
>> > I had something like that as a local patch but that's a bit dangerous.
>>
>> Well, yeh. But somewhat less dangerous than the existing situation!
>>
>> > Imagine a process using lots of stack space before calling writev and
>> > there's only, say, 32K left.
>>
>> Imagine a process using no stack space at all before calling writev and
>> there's only, say, 2Mb left. Oh, hang on, that's where we came in!
>>
>> > It would potentially get a SEGV since
>> > alloca is used while it would still work when using malloc. Of course
>> > malloc could fail for a process using lots of malloc'ed space. However,
>> > malloc should at least not SEGV but just return with a NULL pointer...
>>
>> Indeed, and perhaps the best fix of all would be if alloca was able to
>> return NULL when there wasn't enough space on the stack.
>>
>> > So, I guess I'll just check it in using malloc.
>>
>> 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? Or is it a thread safety issue (global vars, etc)?
signal handlers only work on the main thread.
I am working on a replacement for the use of IsBad*Ptr, though, which is
thread safe and could be pressed into service here.
cgf