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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
