* gcc-4.5.3 segfaults wrt alloca @ 2011-12-09 10:58 Denis Excoffier 2011-12-09 14:31 ` Christopher Faylor 2011-12-09 14:55 ` Ryan Johnson 0 siblings, 2 replies; 9+ messages in thread From: Denis Excoffier @ 2011-12-09 10:58 UTC (permalink / raw) To: cygwin 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. Thank you for your help. Regards, Denis Excoffier. % uname -a CYGWIN_NT-5.1 %%EDITED%% 1.7.10s(0.255/5/3) 20111209 06:57:51 i686 Cygwin % cat foo.cc // // /usr/bin/g++ -o foo foo.cc // #define DONT_USE_NEW int main() { // #ifdef DONT_USE_NEW unsigned int const SIZE = 689471; int foo[SIZE]; #else unsigned int const SIZE = 68947100; int *const foo = new int [SIZE]; #endif for ( unsigned int i = 0 ; i < SIZE ; ++i ) { foo[i] = i; }; #ifdef DONT_USE_NEW #else // missing free #endif return(0); }; % /usr/bin/g++ -o foo foo.cc % ./foo Segmentation fault (core dumped) % /usr/bin/gdb ./foo GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-cygwin". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from %%EDITED%%/foo...done. (gdb) run Starting program: %%EDITED%%/foo [New Thread 3256.0xf44] [New Thread 3256.0x1908] Program received signal SIGSEGV, Segmentation fault. _alloca () at /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/libgcc/../gcc/config/i386/cygwin.asm:45 45 /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/libgcc/../gcc/config/i386/cygwin.asm: No such file or directory. in /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/libgcc/../gcc/config/i386/cygwin.asm (gdb) quit A debugging session is active. Inferior 1 [process 3256] will be killed. Quit anyway? (y or n) y % -- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc-4.5.3 segfaults wrt alloca 2011-12-09 10:58 gcc-4.5.3 segfaults wrt alloca Denis Excoffier @ 2011-12-09 14:31 ` Christopher Faylor 2011-12-09 14:55 ` Ryan Johnson 1 sibling, 0 replies; 9+ messages in thread From: Christopher Faylor @ 2011-12-09 14:31 UTC (permalink / raw) To: cygwin On Fri, Dec 09, 2011 at 11:57:37AM +0059, 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. > >Thank you for your help. > >Regards, > >Denis Excoffier. > > > >% uname -a >CYGWIN_NT-5.1 %%EDITED%% 1.7.10s(0.255/5/3) 20111209 06:57:51 i686 Cygwin >% cat foo.cc >// >// /usr/bin/g++ -o foo foo.cc >// >#define DONT_USE_NEW >int main() { >// >#ifdef DONT_USE_NEW > unsigned int const SIZE = 689471; > int foo[SIZE]; >#else > unsigned int const SIZE = 68947100; > int *const foo = new int [SIZE]; >#endif > for ( unsigned int i = 0 ; i < SIZE ; ++i ) { > foo[i] = i; > }; >#ifdef DONT_USE_NEW >#else > // missing free >#endif > return(0); >}; >% /usr/bin/g++ -o foo foo.cc >% ./foo >Segmentation fault (core dumped) >% /usr/bin/gdb ./foo >GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special) >Copyright (C) 2011 Free Software Foundation, Inc. >License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> >This is free software: you are free to change and redistribute it. >There is NO WARRANTY, to the extent permitted by law. Type "show copying" >and "show warranty" for details. >This GDB was configured as "i686-cygwin". >For bug reporting instructions, please see: ><http://www.gnu.org/software/gdb/bugs/>... >Reading symbols from %%EDITED%%/foo...done. >(gdb) run >Starting program: %%EDITED%%/foo >[New Thread 3256.0xf44] >[New Thread 3256.0x1908] > >Program received signal SIGSEGV, Segmentation fault. >_alloca () > at /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/libgcc/../gcc/config/i386/cygwin.asm:45 >45 /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/libgcc/../gcc/config/i386/cygwin.asm: No such file or directory. > in /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/libgcc/../gcc/config/i386/cygwin.asm >(gdb) quit >A debugging session is active. > > Inferior 1 [process 3256] will be killed. > >Quit anyway? (y or n) y WFM, sorry. cgf % gdb /tmp/foo GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-cygwin". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... /home/cgf/.gdbinit:2: Error in sourced command file: No symbol table is loaded. Use the "file" command. Reading symbols from /tmp/foo...done. (gdb) r Starting program: /tmp/foo [New Thread 1784.0x106c] warning: section .gnu_debuglink not found in /cygdrive/d/cygwin/bin/cygwin1.dbg [New Thread 1784.0xedc] [Inferior 1 (process 1784) exited normally] -- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc-4.5.3 segfaults wrt alloca 2011-12-09 10:58 gcc-4.5.3 segfaults wrt alloca Denis Excoffier 2011-12-09 14:31 ` Christopher Faylor @ 2011-12-09 14:55 ` Ryan Johnson 2011-12-09 17:02 ` Denis Excoffier 2011-12-09 17:07 ` Eric Blake 1 sibling, 2 replies; 9+ messages in thread From: Ryan Johnson @ 2011-12-09 14:55 UTC (permalink / raw) To: cygwin 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. 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc-4.5.3 segfaults wrt alloca 2011-12-09 14:55 ` Ryan Johnson @ 2011-12-09 17:02 ` Denis Excoffier 2011-12-09 17:07 ` Eric Blake 1 sibling, 0 replies; 9+ messages in thread From: Denis Excoffier @ 2011-12-09 17:02 UTC (permalink / raw) To: cygwin On Fri, Dec 09, 2011 at 09:55:18AM -0500, 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. You're right. % ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited open files (-n) 256 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 2034 cpu time (seconds, -t) unlimited max user processes (-u) 256 virtual memory (kbytes, -v) unlimited % ulimit -s 3000 sh: ulimit: stack size: cannot modify limit: Invalid argument % Regards, Denis Excoffier. -- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc-4.5.3 segfaults wrt alloca 2011-12-09 14:55 ` Ryan Johnson 2011-12-09 17:02 ` Denis Excoffier @ 2011-12-09 17:07 ` Eric Blake 2011-12-09 17:41 ` Ryan Johnson 1 sibling, 1 reply; 9+ messages in thread From: Eric Blake @ 2011-12-09 17:07 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1292 bytes --] 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. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 620 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc-4.5.3 segfaults wrt alloca 2011-12-09 17:07 ` Eric Blake @ 2011-12-09 17:41 ` Ryan Johnson 2011-12-09 20:37 ` Corinna Vinschen 0 siblings, 1 reply; 9+ messages in thread From: Ryan Johnson @ 2011-12-09 17:41 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc-4.5.3 segfaults wrt alloca 2011-12-09 17:41 ` Ryan Johnson @ 2011-12-09 20:37 ` Corinna Vinschen 2011-12-10 14:43 ` Dave Korn 0 siblings, 1 reply; 9+ messages in thread From: Corinna Vinschen @ 2011-12-09 20:37 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc-4.5.3 segfaults wrt alloca 2011-12-09 20:37 ` Corinna Vinschen @ 2011-12-10 14:43 ` Dave Korn 2011-12-12 6:53 ` Denis Excoffier 0 siblings, 1 reply; 9+ messages in thread From: Dave Korn @ 2011-12-10 14:43 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gcc-4.5.3 segfaults wrt alloca 2011-12-10 14:43 ` Dave Korn @ 2011-12-12 6:53 ` Denis Excoffier 0 siblings, 0 replies; 9+ messages in thread From: Denis Excoffier @ 2011-12-12 6:53 UTC (permalink / raw) To: cygwin On Sat, Dec 10, 2011 at 02:42:39PM +0000, Dave Korn wrote: >> 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. Me (OP) too. Thank you for the explanations. Denis Excoffier. -- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-12-12 6:53 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-12-09 10:58 gcc-4.5.3 segfaults wrt alloca Denis Excoffier 2011-12-09 14:31 ` Christopher Faylor 2011-12-09 14:55 ` Ryan Johnson 2011-12-09 17:02 ` Denis Excoffier 2011-12-09 17:07 ` Eric Blake 2011-12-09 17:41 ` Ryan Johnson 2011-12-09 20:37 ` Corinna Vinschen 2011-12-10 14:43 ` Dave Korn 2011-12-12 6:53 ` Denis Excoffier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).