gcc-4.5.3 segfaults wrt alloca

Ryan Johnson ryan.johnson@cs.utoronto.ca
Fri Dec 9 17:41:00 GMT 2011


On 09/12/2011 12:07 PM, Eric Blake wrote:
> On 12/09/2011 07:55 AM, Ryan Johnson wrote:
>> On 09/12/2011 5:58 AM, Denis Excoffier wrote:
>>> I use the latest packages and cygwin snapshots. The problem described
>>> below began several snapshots in the past, around beginning of December.
>>>
>>> The following program, with static allocation of a reasonable amount
>>> of data, segfaults, maybe in alloca(). With a smaller size
>>> (eg 10000) it's ok. With new/malloc (even with 100 times more) it's
>>> ok. With C or C++. 100% reproducible.
>>>     unsigned int const SIZE = 689471;
>>>     int foo[SIZE];
>> Reasonable? You're trying to stack-allocate 2.5MB of data. Don't do that
>> -- stack sizes are 2MB or less in most operating systems. Besides, doing
>> anything useful with a buffer that size would completely drown out the
>> overhead of calling malloc.
> Not only that, but stack allocating more than 64k in a single function
> is a recipe for bypassing the guard page and causing windows to silently
> quit your program, rather than letting cygwin catch the guard page
> access and convert it to normal SIGSEGV handling.  To be portable to all
> OS, you should never stack allocate more than 4k in a single function.
It's kind of interesting: when I ran that test case with my home-brew 
gcc-4.6, its alloca() explicitly walks through the proposed allocation 
in 4kB increments to ensure that a stack overflow triggers SIGSEGV right 
away, rather than allow silent data corruption later. I don't know if 
older versions also do this, but maybe that's why it used to "work" and 
now "doesn't work."

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list