ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Segmentation fault is occurred.
This is a part of gdb session:
Breakpoint 1, main (argc=8, argv=0x7fffffd590c8) at podgon4.c:146
146 data_init(fits_massiv,dataptr,max_mag,BINSIZE,n,n,sr[0],sr[1 ]);
(gdb) x/a fits_massiv
0x7fffff8931d0: 0x773ea0
(gdb) print dataptr
$1 = (FILE *) 0x7737e0
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x0000000000403926 in data_init (fits_massiv=Cannot access memory at address 0x7ffffee45b68
) at read_files.c:771
771 data data_init(fitsfile **fits_massiv,FILE *dataptr,float max_mag,float bin_size,int nx,int ny,float sr1,float sr2){
(gdb) x/a fits_massiv
Cannot access memory at address 0x7ffffee45b68
(gdb) print dataptr
Cannot access memory at address 0x7ffffee45b60
We inspect the value of pointers fits_massiv and dataptr at once before call of function data_init. As you can see, all is OK. But as only program calls the function, their values changed and now we haven't access to memory pointed to by they.
How I can eliminate this problem?
Fedora Core 4 gcc 4.0.0 gdb 6.3.0.0
Make sure you're checking the values AFTER the variables have bound to the function. A lot more code would be helpful here, like the caller and the callee functions
This is main ( part after data_init was adandoned):
Code:
int main(int argc, char*argv[]){
if(argc!=8){
fprintf(stderr,"Usage: podgon4 isolist datafile max_mag n znach outfile sr1,sr2\n");
fprintf(stderr," isolist - isochrone file list \n max_mag - maximum magnitude\n");
fprintf(stderr," n - the number of points in which range will be divided\n znach - znachenie, po kotoromu ishutsa regionu\n");
fprintf(stderr," outfile - output file, - represents standart output\n");
fprintf(stderr," sr1,sr2 - radii in arcminutes, between which stars for weights will be used\n");
return EX_USAGE;
}
float f_cur,znach;
char isolist_file[256],isofits_file[256];
char buf_isodan[256],buf_fits[256], prefix[256];
char data_name[256], *tmpptr,datafile_name[256],*vhodfile;
float max_mag,x_te,y_te,iso_t,t_te,outznach;
float **f[NUM_STEP_T];
data glavdata;
//data*data_str_ukaz;
int i, n=0,x_sch,y_sch,t_sch;
int status=0;
int tindex;
float sr[2];
sscanf(argv[7],"%f,%f",sr,sr+1);
fitsfile *fits_massiv[NUM_STEP_T];
FILE *dataptr,*fp,*outfile=NULL;
Region* mas=NULL;
int a=10;
int* pointer=&a;
strcpy(isolist_file, argv[1]);
strcpy(data_name, argv[2]);
max_mag=atof(argv[3]);
//max_rad=atof(argv[3]);
znach=atof(argv[5]);
n=atoi(argv[4]);
vhodfile=argv[6];
if(!n) n=10;
if(!znach) znach=1.4;
outznach=-2;// for raz4 kriteriy
if(strcmp(vhodfile,"-")){
outfile=fopen(vhodfile,"a");
if(!outfile){
fprintf(stderr,"Unable to open for appending file `%s'. Output will be written to stdout\n",vhodfile);
outfile=stdout;
}
}
else{
outfile=stdout;
}
prefix[0]=0;
tmpptr=strrchr(isolist_file,'/');
if (tmpptr!=0){
memcpy(prefix,isolist_file,tmpptr-isolist_file+1);
prefix[tmpptr-isolist_file+1]=0;
}
tmpptr=strrchr(data_name,'/');
if (tmpptr!=0){
strcpy(datafile_name,tmpptr+1);
}
else{
strcpy(datafile_name,data_name);
}
i=0;
dataptr=fopen(data_name, "r");
if(!dataptr){
fprintf(stderr,"Unable to open data file %s\n",data_name);
return EX_NOINPUT;
}
fp=fopen(isolist_file,"r");
if(!fp){
fprintf(stderr,"Unable to open data file '%s'\n",isolist_file);
return EX_NOINPUT;
}
for(i=0;i<NUM_STEP_T && !feof(fp);i++){
fscanf(fp,"log(t)=%f %s %s\n",&iso_t,buf_isodan,buf_fits);
// fprintf(stderr,"iso_t=%f itot=%f i=%d\n",iso_t,itot(i),i);
if(iso_t!=itot(i)){
fprintf(stderr,
"Wrong order of isochrones in isolist file '%s'.\n Isochrones must begin from %f with step %f, theirs number is %d\n",isolist_file,LOW_T,STEP_T,NUM_STEP_T);
return EX_DATAERR;
}
sprintf(isofits_file,"%s%s",prefix,buf_fits);
fits_open_file(fits_massiv+i,isofits_file,READONLY,&status);
// fprintf(stderr,"after fits_open_file\n");
FERR;
}
fclose(fp);
data_init(fits_massiv,dataptr,max_mag,BINSIZE,n,n,sr[0],sr[1]);
return 0;
}
Breakpoint 1, main (argc=8, argv=0x7ffffffa6b58) at podgon4.c:144
144 glavdata=data_init(fits_massiv,dataptr,max_mag,BINSIZE,n,n,sr[0],sr[1]);
(gdb) x/a fits_massiv
0x7fffffae0c50: 0x774ea0
(gdb) print dataptr
$1 = (FILE *) 0x7747e0
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x0000000000403f51 in data_init (fits_massiv=Cannot access memory at address 0x7fffff093598
) at read_files.c:776
776 data data_init(fitsfile **fits_massiv,FILE *dataptr,float max_mag,float bin_size,int nx,int ny,float sr1,float sr2){
(gdb) x/a fits_massiv
Cannot access memory at address 0x7fffff093598
(gdb) print dataptr
Cannot access memory at address 0x7fffff093590
(gdb) bt
#0 0x0000000000403f51 in data_init (fits_massiv=Cannot access memory at address 0x7fffff093598
) at read_files.c:776
#1 0x0000000000400840 in main (argc=8, argv=0x7ffffffa6b58) at podgon4.c:144
As you can see, data_init call is the first call of my own, not library function.
Quote:
Also, step might be running the whole function if it can't find a source line.
It should find line information!
I compiled all files with -g -ggdb keys.
Following code demonstrates it:
Code:
(gdb) break 776
Breakpoint 2 at 0x403f46: file read_files.c, line 776.
(gdb) run
Breakpoint 1, main (argc=8, argv=0x7fffffedd398) at podgon4.c:144
144 glavdata=data_init(fits_massiv,dataptr,max_mag,BINSIZE,n,n,sr[0],sr[1]);
(gdb) s
Breakpoint 2, data_init (fits_massiv=0x0, dataptr=0x0, max_mag=0, bin_size=0, nx=0, ny=0, sr1=0, sr2=0) at read_files.c:776
776 data data_init(fitsfile **fits_massiv,FILE *dataptr,float max_mag,float bin_size,int nx,int ny,float sr1,float sr2){
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x0000000000403f51 in data_init (fits_massiv=Cannot access memory at address 0x7ffffefc9dd8
) at read_files.c:776
776 data data_init(fitsfile **fits_massiv,FILE *dataptr,float max_mag,float bin_size,int nx,int ny,float sr1,float sr2){
Breakpoint 1 in podgon4.c hits, and then breakpoint 2 in read_files.c, and then program receive SIGSEGV. So we can conclude that read_files.o has debugging symbols.
Anyway, there seems to be some missing debugging stuff. For example, here's some output of a project I've got on a breakpoint.
Code:
(gdb) b parse
Breakpoint 1 at 0x8048de4: file parser.c, line 43.
(gdb) r
Starting program: /home/tgoya/csc357/smake/smake
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x431000
Breakpoint 1, parse (table=0xb7e0b008, filename=0x804964f "Smakefile")
at parser.c:43
43 FILE *file=fopen(filename,"rb");
(gdb) bt
#0 parse (table=0xb7e0b008, filename=0x804964f "Smakefile") at parser.c:43
#1 0x080489c9 in main (argc=1, argv=0xbfec9c44) at smake.c:48
notice the lack of a line of code when your breakpoints break. I used "-g -Wall for this project"
I have already marked read_files.c:776 (if you mean mark is 'put breakpoint'):
Quote:
Code:
(gdb) break 776
Breakpoint 2 at 0x403f46: file read_files.c, line 776.
(gdb) run
Breakpoint 1, main (argc=8, argv=0x7fffffedd398) at podgon4.c:144
144 glavdata=data_init(fits_massiv,dataptr,max_mag,BINSIZE,n,n,sr[0],sr[1]);
(gdb) s
Breakpoint 2, data_init (fits_massiv=0x0, dataptr=0x0, max_mag=0, bin_size=0, nx=0, ny=0, sr1=0, sr2=0) at read_files.c:776
776 data data_init(fitsfile **fits_massiv,FILE *dataptr,float max_mag,float bin_size,int nx,int ny,float sr1,float sr2){
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x0000000000403f51 in data_init (fits_massiv=Cannot access memory at address 0x7ffffefc9dd8
) at read_files.c:776
776 data data_init(fitsfile **fits_massiv,FILE *dataptr,float max_mag,float bin_size,int nx,int ny,float sr1,float sr2){
If I mark function data_init, I will receive segfault before breakpoint hits:
Code:
(gdb) break 143
Breakpoint 1 at 0x4007d0: file podgon4.c, line 143.
(gdb) break data_init
Breakpoint 2 at 0x4039df: file read_files.c, line 777.
(gdb) run
Starting program: /home/pioner/auto/podgon4 /home/pioner/iso/make_mask/isochrones/iso.list /home/pioner/iso/make_mask/NGC6819.dat 16 30 -2 results_4raz4/NGC6819.dat_proba30 10,15
Breakpoint 1, main (argc=8, argv=0x7fffffef7f98) at podgon4.c:144
144 glavdata=data_init(fits_massiv,dataptr,max_mag,BINSIZE,n,n,sr[0],sr[1]);
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x000000000040399d in data_init (fits_massiv=Cannot access memory at address 0x7ffffefe4a68
) at read_files.c:776
776 data data_init(fitsfile **fits_massiv,FILE *dataptr,float max_mag,float bin_size,int nx,int ny,float sr1,float sr2){
In this case breakpoint doesn't hit, because it is on line, next to line with function definition.
In previous example I put 'fprintf(stderr,"fdkjjjjjjjjjjjjjjjj\n");' at the beginning of 777 line. If s makes run whole fucntion, 'fdkjjjjjjjjjjjjjjjj' will appear on the screen. But 'fdkjjjjjjjjjjjjjjjj' haven't appeared, so body of the function was not executed.
Quote:
notice the lack of a line of code when your breakpoints break. I used "-g -Wall for this project"
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.