Mail Archives: cygwin/2011/12/09/12:41:44
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
- Raw text -