l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2006 Feb 08 11:47

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] cygwin - segfault on array allocation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] cygwin - segfault on array allocation

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.

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.