Re: gcc-4.5.3 segfaults wrt alloca

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 09/12/2011 20:36, Corinna Vinschen wrote:
> On Dec  9 12:41, Ryan Johnson wrote:
>> 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."
> 
> alloca works this way for ages, as far as I know.

  1. Yes, alloca stack probes.
  2. GCC uses alloca in the prologue of functions that need big stack frames
allocated, in order to gain just that functionality.
  3. Windows will grow the stack for you automatically if you hit a guard page.
  4. A lot depends on the luck of how your process initial space is laid out.
 When I run the testcase and breakpoint at main, $esp = 0x22cd2c; that's only
just over 2 meg anyway, so there's no address space to expand the stack down
into and the seg fault happens when alloca tries to probe reserved low memory
addresses.  If however (cgf's case?) the initial stack is higher up in the
address space, windows will grow it automatically for you as your probes hit
guard pages until you reach the final required size.
  5. Setting the program's initial stack size larger by adding e.g.
"-Wl,-stack,4000000" to the compiler commandline ensures that the initial
stack pointer is located somewhere that at least that much memory is
available, and makes the testcase run OK for me where previously it was faulting.

    cheers,
      DaveK


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