A quit strange coredump

[tomy]

Hi all:
There is an amazing coredump in my C code, I was thinking it over and
over...
The code is simple as below:

//*************************************
const unsigned long int len = 102400000;
int array[len];
unsigned long int i;
for(i=0; i<len; i++)
{
array[i] = 0; //The coredump line;
}
//*************************************

with gdb, when variable i came to 0, the "array[i]=0", the process
received segmentation fault and left coredump. Is there any wrong in
THAT line? It seems all right, with the condition i=0.

--tomy

[Michael Mair]

tomy schrieb:

Hi all:
There is an amazing coredump in my C code, I was thinking it over and
over...
The code is simple as below:

//*************************************
const unsigned long int len = 102400000;
int array[len];
unsigned long int i;
for(i=0; i<len; i++)
{
array[i] = 0; //The coredump line;
}
//*************************************

with gdb, when variable i came to 0, the "array[i]=0", the process
received segmentation fault and left coredump. Is there any wrong in
THAT line? It seems all right, with the condition i=0.

Please break your code down to a minimal compiling example that
still exhibits the problem. Post it here and state whether you
are using C99 or C90.

As you seem to be using gcc, turn the warning level up:
gcc -std=c99 -pedantic -W -O yourcode.c -c
Note: Your code cannot be C90 code (-std=c89 or -ansi) as len
is not a compile time constant which is required for array sizes
in C90. (const does not provide compile time constants in C.)
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Ico]

tomy <to******@gmail.com> wrote:

Hi all:
There is an amazing coredump in my C code, I was thinking it over and
over...
The code is simple as below:

//*************************************
const unsigned long int len = 102400000;
int array[len];
unsigned long int i;
for(i=0; i<len; i++)
{
array[i] = 0; //The coredump line;
}
//*************************************

with gdb, when variable i came to 0, the "array[i]=0", the process
received segmentation fault and left coredump. Is there any wrong in
THAT line? It seems all right, with the condition i=0.

Please provide a complete, standalone, compilable example, instead of
just a snippet. Your post does not make it clear if array[] is an
automatic variable; if this is the case, it's size of nearly 100 MB
might just be too much on your platform.
--
:wq
^X^Cy^K^X^C^C^C^C

[Ben C]

On 2006-06-11, tomy <to******@gmail.com> wrote:

Hi all:
There is an amazing coredump in my C code, I was thinking it over and
over...
The code is simple as below:

//*************************************
const unsigned long int len = 102400000;
int array[len];
unsigned long int i;
for(i=0; i<len; i++)
{
array[i] = 0; //The coredump line;
}
//*************************************

with gdb, when variable i came to 0, the "array[i]=0", the process
received segmentation fault and left coredump. Is there any wrong in
THAT line? It seems all right, with the condition i=0.

I think this program should be OK, assuming it's C99 and assuming your
machine's stack is big enough. The array is rather a big object to put
on the stack, and the coredump may well be caused indirectly by a stack
overflow.

[Keith Thompson]

Ben C <sp******@spam.eggs> writes:

On 2006-06-11, tomy <to******@gmail.com> wrote:

Hi all:
There is an amazing coredump in my C code, I was thinking it over and
over...
The code is simple as below:

//*************************************
const unsigned long int len = 102400000;
int array[len];
unsigned long int i;
for(i=0; i<len; i++)
{
array[i] = 0; //The coredump line;
}
//*************************************

with gdb, when variable i came to 0, the "array[i]=0", the process
received segmentation fault and left coredump. Is there any wrong in
THAT line? It seems all right, with the condition i=0.

I think this program should be OK, assuming it's C99 and assuming your
machine's stack is big enough. The array is rather a big object to put
on the stack, and the coredump may well be caused indirectly by a stack
overflow.

100 megabytes is bigger than the stacksize limit on the machines I use.

Even though "len" is declared const, len is not a constant expression.
That means that
int array[len];
declares a VLA (variable length array, a new feature in C99). VLAs
can be convenient; their biggest drawback, IMHO, is that no mechanism
is defined for reporting an allocation error. The same is true for
any auto (i.e., local) variable; the problem with VLAs isn't really
new, but it's much more visible because you're more likely to run into
it when you don't know the size at compilation time.

If a VLA is too big, the result is undefined behavior. A segmentation
fault on the first attempt to access the VLA is a plausible way for
the undefined behavior to manifest itself.

BTW, I tried a program that incorporated the above code, and it died
with a segmentation fault, though the debugger wasn't very specific
about where it occurred (on one system, it reported that it had
happened on a line containing a printf() before the loop). When I
used a constant expression rather than a const object for the array
length (so it's no longer a VLA), I got the same results.

What you're seeing is probably a stack overflow, and the language
doesn't define a good way to handle those. If you want an object that
big, try to allocate it with malloc(); check the result of malloc() to
see if the object was allocated.o

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Igmar Palsenberg]

tomy wrote:

Hi all:
There is an amazing coredump in my C code, I was thinking it over and
over...
The code is simple as below:

//*************************************
const unsigned long int len = 102400000;
int array[len];
unsigned long int i;
for(i=0; i<len; i++)
{
array[i] = 0; //The coredump line;
}

You're shoving 390 MB on the stack, and expect it to work ?

Igmar

[tomy]

Many Many Thanks
I am a new guy to the c language, and learn a lots from your posts.

The array is allocated in the stacks, and overflow with segmentation
fault. I try to remove the array to the global scope (or malloc() to
the heap mem.), and it works fine there.

But I still hold a question: What the exactly amount of stack memory
the process can take. On the 32bit machine, the stack's virtual memory
is like 0x4000000 ~ 0xc000000, that's 800M.isn't it? My computer has
500M(add 1G swap memory)physically, however I could only allocate about
110M in the stack. that's funny? And How could i find the fresh memory
to use, without maintain the total amount?

Hope that won't bother you to much. Many Many thanks again.

--tomy

[Walter Roberson]

In article <11********************@y43g2000cwc.googlegroups.c om>,
tomy <to******@gmail.com> wrote:

But I still hold a question: What the exactly amount of stack memory
the process can take. On the 32bit machine, the stack's virtual memory
is like 0x4000000 ~ 0xc000000, that's 800M.isn't it?
Depends on the operating system. On the 32 bit machine I'm using
now, I could probably push the stack up to 1.2 Gb, possibly even more.
My computer has
500M(add 1G swap memory)physically, however I could only allocate about
110M in the stack. that's funny?
Operating system dependant. Stacks are sometimes placed below shared
libraries, with the heap being above the shared libraries; on such
systems, the available room for the stack or heap would depend on
the shared library sizes and positions. And of course not all systems
use stacks or heaps.
And How could i find the fresh memory
to use, without maintain the total amount?

If you want to know how much more memory you could allocate, then the
only portable way is to keep allocating memory until you run out.
Unfortunately doing that might have adverse effects on your program or
other things happening on your system, so that's not a very good
method.

Questions about available memory to allocate are often fairly
complex to answer; you really need someone who specializes in
your platform (i.e., in a different newsgroup.)
--
All is vanity. -- Ecclesiastes

[tomy]

I am sorry, just make a mistake. I come to check the allocating amount
again.
As last post mentioned, the VM of stack seems to be 0x40000000 ~
0xc0000000 , which should be 2GB. Right?

And How could you come to the point 390M?

I try the code below
//*****************************************
#define len 10480000 //about 10M

int main()
{
unsigned long int i;
char array[len]; //allocate 10MB
for(i=0; i<len; i++)
{
array[i] = 0; //The coredump line;
}
}
//*******************************************
That works fine! However just 10M, above it, coredump again. OH~~

--tomy

[Walter Roberson]

In article <11**********************@j55g2000cwa.googlegroups .com>,
tomy <to******@gmail.com> wrote:

I am sorry, just make a mistake. I come to check the allocating amount
again.
As last post mentioned, the VM of stack seems to be 0x40000000 ~
0xc0000000 , which should be 2GB. Right?
0x40000000 ~ (0xc0000000 - 1) would be 2 gigabytes in a linear
address space, but that might not a relevant limit. For example on
the 32 bit system I am using right now, all addresses from
0x80000000 to 0xFFFFFFFF are reserved for the operating system and
cannot be allocated to user processes. And there might be a lot of other
factors that affect maximum stack size. You really need to consult
specialists in your platform.

And How could you come to the point 390M?

Please quote context. Please see here for information on how to
do so from Google Groups: http://cfaj.freeshell.org/google/

I cannot tell what the 390M figure is in response to. In the
postings that have made it to my system, no-one has mentioned
390Mb until you. If you are asking how you could get 390 Mb allocated
to the stack for your process then you need to read up on the
details for your platform. The C standard does not even have stacks,
so the C standard discussed in this newsgroup cannot answer any
questions about managing stack allocations on your platform.
--
Prototypes are supertypes of their clones. -- maplesoft

[Keith Thompson]

"tomy" <to******@gmail.com> writes:

Many Many Thanks
I am a new guy to the c language, and learn a lots from your posts.

The array is allocated in the stacks, and overflow with segmentation
fault. I try to remove the array to the global scope (or malloc() to
the heap mem.), and it works fine there.

But I still hold a question: What the exactly amount of stack memory
the process can take. On the 32bit machine, the stack's virtual memory
is like 0x4000000 ~ 0xc000000, that's 800M.isn't it? My computer has
500M(add 1G swap memory)physically, however I could only allocate about
110M in the stack. that's funny? And How could i find the fresh memory
to use, without maintain the total amount?

Please provide context when you post a followup. Until recently,
Google make this unnecessarily difficult, but they seem to have fixed
that.

The C language doesn't specify how much stack space is available (the
standard doesn't even use the word "stack"). The amount of space
available on the system may not be the same as the amount available to
your program. Your system may provide a way to tell you what its
current limits are. <OT>On Unix or Linux, try "limit" or "ulimit".</OT>
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[tomy]

I see, I see...
Thanks for your quit hlepful responses.

--tomy

Walter Roberson wrote:

In article <11**********************@j55g2000cwa.googlegroups .com>,
tomy <to******@gmail.com> wrote:

I am sorry, just make a mistake. I come to check the allocating amount
again.
As last post mentioned, the VM of stack seems to be 0x40000000 ~
0xc0000000 , which should be 2GB. Right?

0x40000000 ~ (0xc0000000 - 1) would be 2 gigabytes in a linear
address space, but that might not a relevant limit. For example on
the 32 bit system I am using right now, all addresses from
0x80000000 to 0xFFFFFFFF are reserved for the operating system and
cannot be allocated to user processes. And there might be a lot of other
factors that affect maximum stack size. You really need to consult
specialists in your platform.

And How could you come to the point 390M?

Please quote context. Please see here for information on how to
do so from Google Groups: http://cfaj.freeshell.org/google/

I cannot tell what the 390M figure is in response to. In the
postings that have made it to my system, no-one has mentioned
390Mb until you. If you are asking how you could get 390 Mb allocated
to the stack for your process then you need to read up on the
details for your platform. The C standard does not even have stacks,
so the C standard discussed in this newsgroup cannot answer any
questions about managing stack allocations on your platform.
--
Prototypes are supertypes of their clones. -- maplesoft

[spibou]

Keith Thompson wrote:

The C language doesn't specify how much stack space is available (the
standard doesn't even use the word "stack"). The amount of space
available on the system may not be the same as the amount available to
your program. Your system may provide a way to tell you what its
current limits are. <OT>On Unix or Linux, try "limit" or "ulimit".</OT>

Actually for stack space (on Unix and similar) one needs to use
getrlimit()

[Keith Thompson]

sp****@gmail.com writes:

Keith Thompson wrote:

The C language doesn't specify how much stack space is available (the
standard doesn't even use the word "stack"). The amount of space
available on the system may not be the same as the amount available to
your program. Your system may provide a way to tell you what its
current limits are. <OT>On Unix or Linux, try "limit" or "ulimit".</OT>

Actually for stack space (on Unix and similar) one needs to use
getrlimit()

<OT>
The "limit" or "ulimit" command is a shell builtin. They probably
call getrlimit().
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.