l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
August 5: Social gathering
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2006 Feb 09 07:36

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



 > 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).
How does one gain this kind of knowledge at fingertips?

(snip)
Well, one way is to occasionally work with less forgiving compilers...then you find out that they're not actually wrong when you bang your head against a wall for some really stupid bug :).

 > 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.
Yeah, did that.  Didn't give any line number associated with the signal.  It
actually said there were corrupted frames on the stack frame.
That's a big red flag. Anyway, have you tried manuually putting

double a[50761]; // also for b, c, d, e

and/or

int a[50761]; // also for b, c, d, e

alternatively,

double a[50761] // also for b, c, d, but NOT e

if you're feeling particularly adventurous and can do your own garbage collection:

double *a, *b, *c, *d, *e;
a = (double*)malloc(sizeof(double)*strtol(...)); // also for b, c, d, e

All these would help decide if you're really just busting through a 2 meg limit on cygwin or not. The first to see if allocating that memory does work, the second to see if arrays "of that size" are an issue or not, the third, well, similar to the first :). The fourth...just because that's the way to actually do this and still make the code portable within official bounds :).

Sorry if I'm being basic Pete, just tossing out ideas here. By the way, congrats on the job, Norm mentioned you had been looking (unless I'm confusing you with someone else, in which case, well, my bad!).


-dan
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
Sunset Systems
Who graciously hosts our website & mailing lists!