Segmentation fault

[Sheldon]

Hello,

Can someone please tell me why this program causes a segmentation
fault:

#include <stdio.h>
#include <stdlib.h>
#define ROW 1215
#define COL 1215
#define FILENAME "/data/aux/test_array.dat"

int main(void)
{
double tmp[ROW][COL];
FILE *fp;
int i, j, data;
float count;
printf("Opening file: %s\n",FILENAME);
return 0;
}

 

[jacob navia]

Hello,

Can someone please tell me why this program causes a segmentation
fault:

#include <stdio.h>
#include <stdlib.h>
#define ROW 1215
#define COL 1215
#define FILENAME "/data/aux/test_array.dat"

int main(void)
{
double tmp[ROW][COL];
FILE *fp;
int i, j, data;
float count;
printf("Opening file: %s\n",FILENAME);
return 0;
}

Because you have asked for an array "tmp" of 11 809 800 bytes
and maybe you do not have so much virtual memory.
The program crashes when the OS realizes that the request
is beyond your quota, or your stack limits.

Change the definition of ROW and COL to be
10 instead of 1215 or make the "tmp" array allocated
in the data section:

double tmp[ROW][COL];

int main(void)
{
}

If that solves the problem, you have asked for more memory
than the stack size. Change either your requirements or the
stack size.

 

[Sheldon]

jacob navia skrev:

Hello,

Can someone please tell me why this program causes a segmentation
fault:

#include <stdio.h>
#include <stdlib.h>
#define ROW 1215
#define COL 1215
#define FILENAME "/data/aux/test_array.dat"

int main(void)
{
double tmp[ROW][COL];
FILE *fp;
int i, j, data;
float count;
printf("Opening file: %s\n",FILENAME);
return 0;
}

Because you have asked for an array "tmp" of 11 809 800 bytes
and maybe you do not have so much virtual memory.
The program crashes when the OS realizes that the request
is beyond your quota, or your stack limits.

Change the definition of ROW and COL to be
10 instead of 1215 or make the "tmp" array allocated
in the data section:

double tmp[ROW][COL];

int main(void)
{
}

If that solves the problem, you have asked for more memory
than the stack size. Change either your requirements or the
stack size.

Thanks!

Sheldon

 

[ramasubramanian.rahul]

hi...
this code is behaving wierd... it does a seg fault when run ( ie
../a.out )...
but when i single step using gdb the program exits normally !!!!
any idea why this is happening ... ???

jacob navia skrev:

Hello,

Can someone please tell me why this program causes a segmentation
fault:

#include <stdio.h>
#include <stdlib.h>
#define ROW 1215
#define COL 1215
#define FILENAME "/data/aux/test_array.dat"

int main(void)
{
double tmp[ROW][COL];
FILE *fp;
int i, j, data;
float count;
printf("Opening file: %s\n",FILENAME);
return 0;
}

Because you have asked for an array "tmp" of 11 809 800 bytes
and maybe you do not have so much virtual memory.
The program crashes when the OS realizes that the request
is beyond your quota, or your stack limits.

Change the definition of ROW and COL to be
10 instead of 1215 or make the "tmp" array allocated
in the data section:

double tmp[ROW][COL];

int main(void)
{
}

If that solves the problem, you have asked for more memory
than the stack size. Change either your requirements or the
stack size.

Thanks!

Sheldon

 

[Sheldon]

(e-mail address removed) skrev:

hi...
this code is behaving wierd... it does a seg fault when run ( ie
./a.out )...
but when i single step using gdb the program exits normally !!!!
any idea why this is happening ... ???

jacob navia skrev:

Sheldon wrote:
Hello,

Can someone please tell me why this program causes a segmentation
fault:

#include <stdio.h>
#include <stdlib.h>
#define ROW 1215
#define COL 1215
#define FILENAME "/data/aux/test_array.dat"

int main(void)
{
double tmp[ROW][COL];
FILE *fp;
int i, j, data;
float count;
printf("Opening file: %s\n",FILENAME);
return 0;
}


Because you have asked for an array "tmp" of 11 809 800 bytes
and maybe you do not have so much virtual memory.
The program crashes when the OS realizes that the request
is beyond your quota, or your stack limits.

Change the definition of ROW and COL to be
10 instead of 1215 or make the "tmp" array allocated
in the data section:

double tmp[ROW][COL];

int main(void)
{
}

If that solves the problem, you have asked for more memory
than the stack size. Change either your requirements or the
stack size.

Thanks!

Sheldon

I wish I could answer. I am using the code to learn C and expanding it
to write and then reading the data.

/Sheldon

 

[jmcgill]

Hello,

Can someone please tell me why this program causes a segmentation
fault:

#define ROW 1215
#define COL 1215
double tmp[ROW][COL];

While you probably cannot do that,
you may be able to do this:

#include <stdio.h>
#include <stdlib.h>
#define ROW 1215
#define COL 1215
#define FILENAME "/data/aux/test_array.dat"

int
main (int argc, char **argv)
{
FILE *fp;
int i, j, data;
float count;
double *tmp;
tmp = malloc(ROW * COL * sizeof(double));
if(NULL==tmp){
printf("out of memory?\n");
exit -1;
}
printf ("Opening file: %s\n", FILENAME);
free(tmp);
return 0;
}

 

[Ancient_Hacker]

hi...
this code is behaving wierd... it does a seg fault when run ( ie
./a.out )...
but when i single step using gdb the program exits normally !!!!
any idea why this is happening ... ???

You're asking for about 4 megabytes of stack space, which might
ordinarily be beyond the default stack size.

Debuggers often handle stack overflows for you by asking the OS for
more stack, so that may be why it runs okay in the debugger.

In general, it's a better idea to allocate large data items with
malloc(), at least then you get control back if memory runs out. With
stack overflows the programs tend to die before you can do anything
about it.

 

[Mark McIntyre]

(e-mail address removed) skrev:


I wish I could answer. I am using the code to learn C and expanding it
to write and then reading the data.

Because your debugger is being friendly and stopping it crashing. Its
not uncommon for things to 'work' in the debugger but then fail in
real life. Its annoying.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan