[vox-tech] cygwin - segfault on array allocation

Matt Roper matt at mattrope.com
Wed Feb 8 10:16:02 PST 2006


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;
>    }
> 
> 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.  I'm guessing the problem is
> memory related because when I remove one of the arrays, the largest number
> that does not cause a segfault increases.
> 
> But it's strange because the machine has a gig of RAM.  With 8 byte doubles,
> each array is only approximately .4MB.
> 
> Any idea what's going on?

Just a guess, but could you be overflowing your stack?  I don't know
much about windows/cygwin, but if it only gives a 2MB stack to your
process then your arrays would be filling that up.  Try running "ulimit
-a" at your console (or whatever is appropriate if cygwin uses a shell
other than bash).

If you allocate those arrays on the heap, do you still have problems?


Matt

-- 

*************************************************
* Matt Roper <matt at mattrope.com>                *
* http://www.mattrope.com                       *
* PGP Key: http://www.mattrope.com/mattrope.asc *
*************************************************


More information about the vox-tech mailing list