[vox-tech] cygwin - segfault on array allocation

[Micah J. Cowan]

On Wed, Feb 08, 2006 at 12:12:19PM -0500, Peter Jay Salzman wrote:
> i'm finding that cygwin segfaults on a very simple program:
> 
>    #include <iostream>
>    using std::cout;
>    using std::endl;
>    // 50760 is the last
> 
>    int main( int argc, char *argv[] )
>    {
>       const long int N = strtol(argv[1], (char **)0, 0);
>       double a[N], b[N], c[N], d[N], ans[N];
> 
>       return 0;
>    }

First: note that the above is not portable code. C++ does not support
variable-length arrays (that is, the bracketed expression must be a
constant). As long as you're constraining yourself to g++, though, or
other ones that support this extension, you're fine. (VLAs /are/
supported in the current version of the ISO C Standard, BTW).

However, with VLAs, you have the following problem. There is an
implementation-defined maximum value for the size of these things--and
that only has to be supported for the definition of /one/ of these.

In practical terms, this means you may be limited by the size of the
stack. Since the objects you are allocating are hu-YUDGE, this is not
surprising. Unfortunately, like any other stack-space related problem
(other large, non-VL arrays, deep recursion), there is no portable way
to /catch/ them. Which is a strong reason why you should at least avoid
using them for big ones.

Since you're using C++, I highly recommend using std::vector instead.

> It does not segfault when N=50760 but does segfault when N=50761.  In GDB:
> 
>    $ gdb arg.exe
>    GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
>    (gdb) set args 50761
>    (gdb) break 1
>    Breakpoint 1 at 0x401050: file arg.cc, line 1.
>    (gdb) run
>    Starting program: /cygdrive/c/Documents and
>    Settings/psalzman/home/tests/args/arg.exe 50761
> 
>    Breakpoint 1, main (argc=2, argv=0x4c2b90) at arg.cc:7
>    7       {
>    (gdb) n
> 
>    Program received signal SIGSEGV, Segmentation fault.
>    0x610ae938 in pthread_key_create () from /usr/bin/cygwin1.dll
>    (gdb)
> 
> which is odd; I don't believe this line number.

What line number? It didn't break at 7, it broke after you "stepped"
after 7, which means you don't necessarily know where it broke. I
usually let segfaulting programs dump core, and then use gdb to examine
where it was when it got the signal. I don't think you'll get very
useful information that way for this example, however.

HTH,
Micah