fscanf - segfault - Address 0x0 is not stack'd, malloc'd or (recently) free'd

jkobori · 11-19-2012, 02:11 PM

Hi everybody!

My problem is the following:
I would like to run a C code, and I can compile it without errors,
but during the run it gives a segfault.

The relevant part of the code:

Code:

#include<stdio.h>
#include<stdlib.h>
#include<math.h>

main(int argc, char *argv[])
{
	//Declaration of variables and functions:

	FILE *fp_dat, *fp_scp, *fp_d8, *fp_dat_line, *fp_scp_line, *fp_inf, *fp_poz, *fp_detector, *fp_nap;

	fp_dat=fopen(argv[1],"r");
	fp_scp=fopen(argv[2],"r");
	fp_d8=fopen(argv[3],"w");
	fp_dat_line=fopen(argv[4],"r");
	fp_scp_line=fopen(argv[5],"r");
	fp_inf=fopen(argv[6],"r");
	fp_poz=fopen(argv[7],"r");
	fp_detector=fopen(argv[8],"r");
	fp_nap=fopen(argv[9],"r");
	
	char grb[10];
	sprintf(grb, "%s", argv[10]);

		int dat_line, scp_line, sor,ret;
line 36:	fscanf(fp_dat_line,"%d",&dat_line);
		printf("%d ajaj\n", dat_line);
		fscanf(fp_scp_line,"%d",&scp_line);

I checked the code with valgrind, the result is here:

Code:

--16922-- REDIR: 0x40189e0 (strlen) redirected to 0x3806ce31 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--16922-- Reading syms from /usr/local/lib/valgrind/vgpreload_core-amd64-linux.so
--16922-- Reading syms from /usr/local/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--16922-- REDIR: 0x4018850 (index) redirected to 0x4c2cc80 (index)
--16922-- REDIR: 0x40188d0 (strcmp) redirected to 0x4c2dd40 (strcmp)
--16922-- Reading syms from /lib/x86_64-linux-gnu/libm-2.15.so
--16922--   Considering /lib/x86_64-linux-gnu/libm-2.15.so ..
--16922--   .. CRC mismatch (computed e81d4037 wanted fad28d48)
--16922--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.15.so ..
--16922--   .. CRC is valid
--16922-- Reading syms from /lib/x86_64-linux-gnu/libc-2.15.so
--16922--   Considering /lib/x86_64-linux-gnu/libc-2.15.so ..
--16922--   .. CRC mismatch (computed 3af7ebbf wanted 50fc58fa)
--16922--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.15.so ..
--16922--   .. CRC is valid
--16922-- REDIR: 0x51bce30 (strcasecmp) redirected to 0x4a2560a (_vgnU_ifunc_wrapper)
--16922-- REDIR: 0x51b91d0 (strnlen) redirected to 0x4a2560a (_vgnU_ifunc_wrapper)
--16922-- REDIR: 0x51bf100 (strncasecmp) redirected to 0x4a2560a (_vgnU_ifunc_wrapper)
--16922-- REDIR: 0x51babc0 (__GI_strrchr) redirected to 0x4c2caa0 (__GI_strrchr)
--16922-- REDIR: 0x51b2f40 (malloc) redirected to 0x4c2c5ed (malloc)
--16922-- REDIR: 0x51b3580 (free) redirected to 0x4c2b552 (free)
--16922-- REDIR: 0x51b8a40 (strcpy) redirected to 0x4a2560a (_vgnU_ifunc_wrapper)
--16922-- REDIR: 0x51b8a80 (__GI_strcpy) redirected to 0x4c2d0d0 (__GI_strcpy)
==16922== Invalid read of size 4
==16922==    at 0x518E35A: __isoc99_fscanf (isoc99_fscanf.c:31)
==16922==    by 0x400AF7: main (lightcurve.c:36)
==16922==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16922== 
==16922== 
==16922== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==16922==  Access not within mapped region at address 0x0
==16922==    at 0x518E35A: __isoc99_fscanf (isoc99_fscanf.c:31)
==16922==    by 0x400AF7: main (lightcurve.c:36)
==16922==  If you believe this happened as a result of a stack
==16922==  overflow in your program's main thread (unlikely but
==16922==  possible), you can try to increase the size of the
==16922==  main thread stack using the --main-stacksize= flag.
==16922==  The main thread stack size used in this run was 8388608.
==16922== 
==16922== HEAP SUMMARY:
==16922==     in use at exit: 3,976 bytes in 7 blocks
==16922==   total heap usage: 9 allocs, 2 frees, 5,112 bytes allocated
==16922== 
==16922== Searching for pointers to 7 not-freed blocks
==16922== Checked 85,192 bytes
==16922== 
==16922== 568 bytes in 1 blocks are still reachable in loss record 1 of 7
==16922==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16922==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16922==    by 0x40098B: main (lightcurve.c:22)
==16922== 
==16922== 568 bytes in 1 blocks are still reachable in loss record 2 of 7
==16922==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16922==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16922==    by 0x4009B0: main (lightcurve.c:23)
==16922== 
==16922== 568 bytes in 1 blocks are still reachable in loss record 3 of 7
==16922==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16922==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16922==    by 0x4009D5: main (lightcurve.c:24)
==16922== 
==16922== 568 bytes in 1 blocks are still reachable in loss record 4 of 7
==16922==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16922==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16922==    by 0x400A1F: main (lightcurve.c:26)
==16922== 
==16922== 568 bytes in 1 blocks are still reachable in loss record 5 of 7
==16922==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16922==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16922==    by 0x400A44: main (lightcurve.c:27)
==16922== 
==16922== 568 bytes in 1 blocks are still reachable in loss record 6 of 7
==16922==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16922==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16922==    by 0x400A8E: main (lightcurve.c:29)
==16922== 
==16922== 568 bytes in 1 blocks are still reachable in loss record 7 of 7
==16922==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16922==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16922==    by 0x400AB3: main (lightcurve.c:30)
==16922== 
==16922== LEAK SUMMARY:
==16922==    definitely lost: 0 bytes in 0 blocks
==16922==    indirectly lost: 0 bytes in 0 blocks
==16922==      possibly lost: 0 bytes in 0 blocks
==16922==    still reachable: 3,976 bytes in 7 blocks
==16922==         suppressed: 0 bytes in 0 blocks
==16922== 
==16922== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==16922== 
==16922== 1 errors in context 1 of 1:
==16922== Invalid read of size 4
==16922==    at 0x518E35A: __isoc99_fscanf (isoc99_fscanf.c:31)
==16922==    by 0x400AF7: main (lightcurve.c:36)
==16922==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16922== 
==16922== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Szegmentálási hiba (core készült)
jkobori@itl87:/data/fermi/080805584$ valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes ./lightcurve ./dat/080805584n3.dat0 ./pos/080805584.scp0 ./d8/080805584n3.d8 ./dat/080805584.dat_line ./pos/080805584.scp_line ./dat/080805584.inf0 ./pos/080805584.detector ./pos/080805584.poz0 ./pos/080805584.nap 080805584
==16924== Memcheck, a memory error detector
==16924== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==16924== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==16924== Command: ./lightcurve ./dat/080805584n3.dat0 ./pos/080805584.scp0 ./d8/080805584n3.d8 ./dat/080805584.dat_line ./pos/080805584.scp_line ./dat/080805584.inf0 ./pos/080805584.detector ./pos/080805584.poz0 ./pos/080805584.nap 080805584
==16924== 
--16924-- Valgrind options:
--16924--    -v
--16924--    --tool=memcheck
--16924--    --leak-check=full
--16924--    --show-reachable=yes
--16924-- Contents of /proc/version:
--16924--   Linux version 3.2.0-30-generic (buildd@batsu) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012
--16924-- Arch and hwcaps: AMD64, amd64-sse3-cx16-lzcnt
--16924-- Page sizes: currently 4096, max supported 4096
--16924-- Valgrind library directory: /usr/local/lib/valgrind
--16924-- Reading syms from /data/fermi/080805584/lightcurve
--16924-- Reading syms from /lib/x86_64-linux-gnu/ld-2.15.so
--16924--   Considering /lib/x86_64-linux-gnu/ld-2.15.so ..
--16924--   .. CRC mismatch (computed eabdc7b7 wanted 3ee54b4e)
--16924--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.15.so ..
--16924--   .. CRC is valid
--16924-- Reading syms from /usr/local/lib/valgrind/memcheck-amd64-linux
--16924--    object doesn't have a dynamic symbol table
--16924-- Scheduler: using generic scheduler lock implementation.
--16924-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
==16924== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-16924-by-jkobori-on-???
==16924== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-16924-by-jkobori-on-???
==16924== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-16924-by-jkobori-on-???
==16924== 
==16924== TO CONTROL THIS PROCESS USING vgdb (which you probably
==16924== don't want to do, unless you know exactly what you're doing,
==16924== or are doing some strange experiment):
==16924==   /usr/local/lib/valgrind/../../bin/vgdb --pid=16924 ...command...
==16924== 
==16924== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==16924==   /path/to/gdb ./lightcurve
==16924== and then give GDB the following command
==16924==   target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=16924
==16924== --pid is optional if only one valgrind process is running
==16924== 
--16924-- REDIR: 0x40189e0 (strlen) redirected to 0x3806ce31 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--16924-- Reading syms from /usr/local/lib/valgrind/vgpreload_core-amd64-linux.so
--16924-- Reading syms from /usr/local/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--16924-- REDIR: 0x4018850 (index) redirected to 0x4c2cc80 (index)
--16924-- REDIR: 0x40188d0 (strcmp) redirected to 0x4c2dd40 (strcmp)
--16924-- Reading syms from /lib/x86_64-linux-gnu/libm-2.15.so
--16924--   Considering /lib/x86_64-linux-gnu/libm-2.15.so ..
--16924--   .. CRC mismatch (computed e81d4037 wanted fad28d48)
--16924--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.15.so ..
--16924--   .. CRC is valid
--16924-- Reading syms from /lib/x86_64-linux-gnu/libc-2.15.so
--16924--   Considering /lib/x86_64-linux-gnu/libc-2.15.so ..
--16924--   .. CRC mismatch (computed 3af7ebbf wanted 50fc58fa)
--16924--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.15.so ..
--16924--   .. CRC is valid
--16924-- REDIR: 0x51bce30 (strcasecmp) redirected to 0x4a2560a (_vgnU_ifunc_wrapper)
--16924-- REDIR: 0x51b91d0 (strnlen) redirected to 0x4a2560a (_vgnU_ifunc_wrapper)
--16924-- REDIR: 0x51bf100 (strncasecmp) redirected to 0x4a2560a (_vgnU_ifunc_wrapper)
--16924-- REDIR: 0x51babc0 (__GI_strrchr) redirected to 0x4c2caa0 (__GI_strrchr)
--16924-- REDIR: 0x51b2f40 (malloc) redirected to 0x4c2c5ed (malloc)
--16924-- REDIR: 0x51b3580 (free) redirected to 0x4c2b552 (free)
--16924-- REDIR: 0x51b8a40 (strcpy) redirected to 0x4a2560a (_vgnU_ifunc_wrapper)
--16924-- REDIR: 0x51b8a80 (__GI_strcpy) redirected to 0x4c2d0d0 (__GI_strcpy)
==16924== Invalid read of size 4
==16924==    at 0x518E35A: __isoc99_fscanf (isoc99_fscanf.c:31)
==16924==    by 0x400AF7: main (lightcurve.c:36)
==16924==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16924== 
==16924== 
==16924== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==16924==  Access not within mapped region at address 0x0
==16924==    at 0x518E35A: __isoc99_fscanf (isoc99_fscanf.c:31)
==16924==    by 0x400AF7: main (lightcurve.c:36)
==16924==  If you believe this happened as a result of a stack
==16924==  overflow in your program's main thread (unlikely but
==16924==  possible), you can try to increase the size of the
==16924==  main thread stack using the --main-stacksize= flag.
==16924==  The main thread stack size used in this run was 8388608.
==16924== 
==16924== HEAP SUMMARY:
==16924==     in use at exit: 3,976 bytes in 7 blocks
==16924==   total heap usage: 9 allocs, 2 frees, 5,112 bytes allocated
==16924== 
==16924== Searching for pointers to 7 not-freed blocks
==16924== Checked 85,192 bytes
==16924== 
==16924== 568 bytes in 1 blocks are still reachable in loss record 1 of 7
==16924==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16924==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16924==    by 0x40098B: main (lightcurve.c:22)
==16924== 
==16924== 568 bytes in 1 blocks are still reachable in loss record 2 of 7
==16924==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16924==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16924==    by 0x4009B0: main (lightcurve.c:23)
==16924== 
==16924== 568 bytes in 1 blocks are still reachable in loss record 3 of 7
==16924==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16924==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16924==    by 0x4009D5: main (lightcurve.c:24)
==16924== 
==16924== 568 bytes in 1 blocks are still reachable in loss record 4 of 7
==16924==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16924==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16924==    by 0x400A1F: main (lightcurve.c:26)
==16924== 
==16924== 568 bytes in 1 blocks are still reachable in loss record 5 of 7
==16924==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16924==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16924==    by 0x400A44: main (lightcurve.c:27)
==16924== 
==16924== 568 bytes in 1 blocks are still reachable in loss record 6 of 7
==16924==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16924==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16924==    by 0x400A8E: main (lightcurve.c:29)
==16924== 
==16924== 568 bytes in 1 blocks are still reachable in loss record 7 of 7
==16924==    at 0x4C2C66F: malloc (vg_replace_malloc.c:270)
==16924==    by 0x519F20A: __fopen_internal (iofopen.c:76)
==16924==    by 0x400AB3: main (lightcurve.c:30)
==16924== 
==16924== LEAK SUMMARY:
==16924==    definitely lost: 0 bytes in 0 blocks
==16924==    indirectly lost: 0 bytes in 0 blocks
==16924==      possibly lost: 0 bytes in 0 blocks
==16924==    still reachable: 3,976 bytes in 7 blocks
==16924==         suppressed: 0 bytes in 0 blocks
==16924== 
==16924== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==16924== 
==16924== 1 errors in context 1 of 1:
==16924== Invalid read of size 4
==16924==    at 0x518E35A: __isoc99_fscanf (isoc99_fscanf.c:31)
==16924==    by 0x400AF7: main (lightcurve.c:36)
==16924==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16924== 
==16924== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

It seems it has a problem with the fscanf lines, but the weird thing is that
the code runs without any segfault for some input files, while for others
gives the error above. The format of the input files are completely the same, except
they contain different numbers.

Can you help me out?

Thank you very much!

Cheers,
Joe

johnsfine · 11-19-2012, 02:29 PM

Add some code to test whether each fopen actually worked.

Your seg fault during fscanf is caused by an earlier failure of fopen.

When fopen fails (for whatever reason) the FILE* is returns is zero. When you pass a zero FILE* to fscanf, it seg faults exactly as you have shown.

Quote:

Originally Posted by jkobori

The relevant part of the code:

Not all the relevant part, since you didn't include the declaration of dat_line, which is quite relevant to the point of failure. Fortunately, we don't need that to diagnose an error this simple.

If you post any code for harder issues, please be more careful to include all the relevant code.

Quote:

Originally Posted by jkobori

the weird thing is that
the code runs without any segfault for some input files, while for others
gives the error above. The format of the input files are completely the same, except
they contain different numbers.

I expect the input files it didn't work for are ones whose names you typed incorrectly on the command line (so the format/contents of such files never mattered). But I didn't see the command line nor the directory of files, so more obscure reasons for the fopen failing are also possible.

jkobori · 11-19-2012, 04:31 PM

OK, here is a little bit more, but I can't paste here the entire code, because it is very long,
and a little bit copyrighted...
Anyway, the rest of it is doing some calculations.
But what do you mean that seg fault during fscanf is caused by an earlier failure of fopen?

Code:

#include<stdio.h>
#include<stdlib.h>
#include<math.h>



main(int argc, char *argv[])
{
	//Declaration of variables and functions:

	FILE *fp_dat, *fp_scp, *fp_d8, *fp_dat_line, *fp_scp_line, *fp_inf, *fp_poz, *fp_detector, *fp_nap;

	fp_dat=fopen(argv[1],"r");
	fp_scp=fopen(argv[2],"r");
	fp_d8=fopen(argv[3],"w");
	fp_dat_line=fopen(argv[4],"r");
	fp_scp_line=fopen(argv[5],"r");
	fp_inf=fopen(argv[6],"r");
	fp_poz=fopen(argv[7],"r");
	fp_detector=fopen(argv[8],"r");
	fp_nap=fopen(argv[9],"r");
	
	char grb[10];
	sprintf(grb, "%s", argv[10]);

	int dat_line, scp_line, sor,ret;
	fscanf(fp_dat_line,"%d",&dat_line);
	printf("%d ajaj\n", dat_line);
	fscanf(fp_scp_line,"%d",&scp_line);

	
	double TIME[dat_line], EXPOSURE[dat_line];
	int COUNTS_1[dat_line], COUNTS_2[dat_line], COUNTS_3[dat_line], COUNTS_4[dat_line], COUNTS_5[dat_line], COUNTS_6[dat_line], COUNTS_7[dat_line], COUNTS_8[dat_line];

	double START[scp_line],STOP[scp_line],LAT_GEO[scp_line],LON_GEO[scp_line],RAD_GEO[scp_line],RA_ZENITH[scp_line],DEC_ZENITH[scp_line],B_MCILWAIN[scp_line],L_MCILWAIN[scp_line],GEOMAG_LAT[scp_line],RA_SCZ[scp_line], DEC_SCZ[scp_line], RA_SCX[scp_line], DEC_SCX[scp_line],RA_NPOLE[scp_line],DEC_NPOLE[scp_line],ROCK_ANGLE[scp_line],QSJ_1[scp_line],QSJ_2[scp_line],QSJ_3[scp_line],QSJ_4[scp_line],SC_X[scp_line],SC_Y[scp_line],SC_Z[scp_line];
	
	double TRIGTIME, RA, DEC;
	int detector, trigger;	
	int i=0,k=0; //j=0,
	
	double ido[dat_line], EXP[dat_line], E[dat_line];										
	int c_1[dat_line], c_2[dat_line], c_3[dat_line], c_4[dat_line], c_5[dat_line], c_6[dat_line], c_7[dat_line], c_8[dat_line];		
	int c1[dat_line], c2[dat_line], c3[dat_line], c4[dat_line], c5[dat_line], c6[dat_line], c7[dat_line], c8[dat_line];			-
	double bin, binmeret;
	double PI=acos(-1.0);	
	
	void interpol(double *START, double *ido, double harminc, double *PAR_SC, double *PAR, int i, int k);
	void interpolradec(double *START, double *ido, double harminc, double *RA_SC, double *DEC_SC, double *RA, double *DEC, int i, int k);

	//Reading data:
	
	fscanf(fp_detector,"%lf",&bin);
	fscanf(fp_detector,"%d %d",&detector,&trigger);
	fclose(fp_detector);
	fp_detector=fopen(argv[8],"w");
	fscanf(fp_inf,"%lf",&TRIGTIME);
	fscanf(fp_poz,"%lf %lf",&RA,&DEC);
	
	for(i=0; i<dat_line; i++)
	{
		fscanf(fp_dat,"%lf %d %d %d %d %d %d %d %d %lf",&TIME[i],&COUNTS_1[i],&COUNTS_2[i],&COUNTS_3[i],&COUNTS_4[i],&COUNTS_5[i],&COUNTS_6[i],&COUNTS_7[i],&COUNTS_8[i],&EXPOSURE[i]);


//		fscanf(fp_dat,"%lf %d %d %d %d %d %d %d %d %lf",&TIME[i],&COUNTS_1[i],&COUNTS_2[i],&COUNTS_3[i],&COUNTS_4[i],&COUNTS_5[i],&COUNTS_6[i],&COUNTS_7[i],&COUNTS_8[i],&EXPOSURE[i]);
		c_1[i]=COUNTS_1[i];c_2[i]=COUNTS_2[i];c_3[i]=COUNTS_3[i];c_4[i]=COUNTS_4[i];c_5[i]=COUNTS_5[i];c_6[i]=COUNTS_6[i];c_7[i]=COUNTS_7[i];c_8[i]=COUNTS_8[i];
		c1[i]=-100;c2[i]=-100;c3[i]=-100;c4[i]=-100;c5[i]=-100;c6[i]=-100;c7[i]=-100;c8[i]=-100;
		EXP[i]=EXPOSURE[i];
	}
printf("%lf\n", EXPOSURE[100]);
printf("%lf %d %d %d %d %d %d %d %d %lf\n",TIME[0],COUNTS_1[0],COUNTS_2[0],COUNTS_3[0],COUNTS_4[0],COUNTS_5[0],COUNTS_6[0],COUNTS_7[0],COUNTS_8[0],EXPOSURE[0]);

//printf("%lf %d %d %d %d %d %d %d %d %lf",TIME[dat_line-1],COUNTS_1[dat_line-1],COUNTS_2[dat_line-1],COUNTS_3[dat_line-1],COUNTS_4[dat_line-1],COUNTS_5[dat_line-1],COUNTS_6[dat_line-1],COUNTS_7[dat_line-1],COUNTS_8[dat_line-1],EXPOSURE[dat_line-1]);



	for(i=0; i<scp_line; i=i+1)
	{
		fscanf(fp_scp,"%lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf",&START[i],&STOP[i],&LAT_GEO[i],&LON_GEO[i],&RAD_GEO[i],&RA_ZENITH[i],&DEC_ZENITH[i],&B_MCILWAIN[i],&L_MCILWAIN[i],&GEOMAG_LAT[i],&RA_SCZ[i],&DEC_SCZ[i],&RA_SCX[i],&DEC_SCX[i],&RA_NPOLE[i],&DEC_NPOLE[i],&ROCK_ANGLE[i],&QSJ_1[i],&QSJ_2[i],&QSJ_3[i],&QSJ_4[i],&SC_X[i],&SC_Y[i],&SC_Z[i]); //+
		//printf("%lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf %lf\n",START[i],STOP[i],LAT_GEO[i],LON_GEO[i],RAD_GEO[i],RA_ZENITH[i],DEC_ZENITH[i],B_MCILWAIN[i],L_MCILWAIN[i],GEOMAG_LAT[i],RA_SCZ[i],DEC_SCZ[i],RA_SCX[i],DEC_SCX[i],RA_NPOLE[i],DEC_NPOLE[i],ROCK_ANGLE[i],QSJ_1[i],QSJ_2[i],QSJ_3[i],QSJ_4[i],SC_X[i],SC_Y[i],SC_Z[i]); //+
	}

Joe

dwhitney67 · 11-19-2012, 06:06 PM

Quote:

Originally Posted by jkobori

OK, here is a little bit more, ...

Not necessary. Please re-read Johnfine's post, specifically the second paragraph (sentence).

Otherwise, you can try out this simple program that duplicates exactly the problem you are experiencing with your program:

Code:

#include <stdio.h>

int main(int argc, char* argv[])
{
    int someValue = 0;

    FILE* fp = fopen("/root/foo", "r");

    //if (fp != NULL)
    //{
        fscanf(fp, "%d", &someValue);
    //}
    //else
    //{
    //    fprintf(stderr, "Error:  Unable to open file '/root/foo'\n");
    //}

    return 0;
}

To fix the problem with the code above, merely comment in the code that I have commented out. See the difference between the code above and your code??

jkobori · 11-20-2012, 03:24 AM

Well, the only difference I can see is the place of *, and the error check, which is commented out.
The "problem" is, that all of the fscanf's work, i.e. I can printf them out to stdout.
So, the real question is that how is that possible (fscanf's work, and give error message at the same time)?
The input files are parameters, so I can not specify them exactly in the code.

Anyway, thanks for your reply!

dwhitney67 · 11-20-2012, 04:54 AM

Quote:

Originally Posted by jkobori

Well, the only difference I can see is the place of *, and the error check, which is commented out.
The "problem" is, that all of the fscanf's work, i.e. I can printf them out to stdout.
So, the real question is that how is that possible (fscanf's work, and give error message at the same time)?
The input files are parameters, so I can not specify them exactly in the code.

Anyway, thanks for your reply!

What I neglected to show in my example code (because of my carelessness) is that one should also check the return value from fscanf() to ensure that it reports the correct number of values successfully parsed.

If you take the code I presented earlier, compile it similar to what you do for your application, and then run it through valgrind, you will see the exact same error being reported as you indicated in your opening post of this thread. Coincidence? I think not.

jkobori · 11-20-2012, 05:39 AM

OK, then my question is that how can I heck the return value from fscanf() ?
I'm not sure I understand what You try to explain me.

dwhitney67 · 11-20-2012, 05:45 AM

Quote:

Originally Posted by jkobori

OK, then my question is that how can I heck the return value from fscanf() ?
I'm not sure I understand what You try to explain me.

If I'm using fscanf() to parse a comma-separated-value (CSV) file containing two integer values, then something like this would work:

Code:

int val1, val2;
int fields = 0;
...
fields = fscanf(fp, "%d,%d", &val1, &val2);

if (fields != 2)
{
    /* error */
}

johnsfine · 11-20-2012, 06:35 AM

The part of my first post you need to understand:

Quote:

Originally Posted by johnsfine

When fopen fails (for whatever reason) the FILE* is returns is zero. When you pass a zero FILE* to fscanf, it seg faults exactly as you have shown.

Quote:

Originally Posted by jkobori

what do you mean that seg fault during fscanf is caused by an earlier failure of fopen?

That is exactly what I explained above. I don't know a better way to say it than I already have.

dwhitney67 wrote sample code to demonstrate what I meant and what you should do about it. But you seem to have gotten bogged down in minor details and side issues of that code and missed the main point.

Check the value returned by fopen. If it is zero, the fopen has failed. A zero FILE* returned by fopen should not be passed to fscanf.

jkobori · 11-20-2012, 06:46 AM

Actually, I've already checked the return value of fopen, and it is correct, so, not a zero file* is passed to fscanf, it is sure.
My main problem is: "The "problem" is, that all of the fscanf's work, i.e. I can printf them out to stdout."
and: "Your seg fault during fscanf is caused by an earlier failure of fopen." Where?

Thanks!

dwhitney67 · 11-20-2012, 06:51 AM

Quote:

Originally Posted by jkobori

It seems it has a problem with the fscanf lines, but the weird thing is that
the code runs without any segfault for some input files, while for others
gives the error above. The format of the input files are completely the same, except
they contain different numbers.

Valgrind is telling you what the problem is. You can duplicate this same anomaly using a trivial program similar to what I presented earlier in which the program fails to open a file and then attempts a call to fscanf().

Earlier you indicated that the program works with a certain collection of files, but yet fails when using others. Besides inserting proper error checking statements in your code, you should also verify that you have proper privileges to read/write the files you are dealing with.

jkobori · 11-20-2012, 07:08 AM

I have tried your sample code, and I understand why it fails.
But my point is, that fopen and fscanf work fine, all the error checking are positive, the code can open the files,
the fscanf read them, I can printf them out again, everything seem to be correct.
I have read/write privilegies on all of the files.

What I do not understand, that how can the fscanf work anf give error at the same time.
By the way, if I compile the code with the -O2 option then it gives the error message for ALL input parameter files.

I think I'm going to try another method, if there is an another.

Thanks!

johnsfine · 11-20-2012, 07:44 AM

Quote:

Originally Posted by jkobori

Actually, I've already checked the return value of fopen, and it is correct, so, not a zero file* is passed to fscanf, it is sure.

I don't see how the Valgrind results you posted initially could represent anything other than a failure to open the file resulting in the seg fault during scanf.

But that may mean you provided that file name incorrectly just when using Valgrind, but are seeing some unrelated error when you run the same program outside of Valgrind.