LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 11-19-2012, 02:11 PM   #1
jkobori
LQ Newbie
 
Registered: Sep 2012
Location: Budapest, Hungary
Distribution: Ubuntu Hardy Heron 8.04.3, Ubuntu x64 12.04
Posts: 19

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


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
 
Old 11-19-2012, 02:29 PM   #2
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,107

Rep: Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114
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 View Post
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 View Post
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.

Last edited by johnsfine; 11-19-2012 at 02:37 PM.
 
Old 11-19-2012, 04:31 PM   #3
jkobori
LQ Newbie
 
Registered: Sep 2012
Location: Budapest, Hungary
Distribution: Ubuntu Hardy Heron 8.04.3, Ubuntu x64 12.04
Posts: 19

Original Poster
Rep: Reputation: Disabled
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
 
Old 11-19-2012, 06:06 PM   #4
dwhitney67
Senior Member
 
Registered: Jun 2006
Location: Maryland
Distribution: Kubuntu, Fedora, RHEL
Posts: 1,523

Rep: Reputation: 332Reputation: 332Reputation: 332Reputation: 332
Quote:
Originally Posted by jkobori View Post
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??
 
Old 11-20-2012, 03:24 AM   #5
jkobori
LQ Newbie
 
Registered: Sep 2012
Location: Budapest, Hungary
Distribution: Ubuntu Hardy Heron 8.04.3, Ubuntu x64 12.04
Posts: 19

Original Poster
Rep: Reputation: Disabled
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!
 
Old 11-20-2012, 04:54 AM   #6
dwhitney67
Senior Member
 
Registered: Jun 2006
Location: Maryland
Distribution: Kubuntu, Fedora, RHEL
Posts: 1,523

Rep: Reputation: 332Reputation: 332Reputation: 332Reputation: 332
Quote:
Originally Posted by jkobori View Post
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.
 
Old 11-20-2012, 05:39 AM   #7
jkobori
LQ Newbie
 
Registered: Sep 2012
Location: Budapest, Hungary
Distribution: Ubuntu Hardy Heron 8.04.3, Ubuntu x64 12.04
Posts: 19

Original Poster
Rep: Reputation: Disabled
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.
 
Old 11-20-2012, 05:45 AM   #8
dwhitney67
Senior Member
 
Registered: Jun 2006
Location: Maryland
Distribution: Kubuntu, Fedora, RHEL
Posts: 1,523

Rep: Reputation: 332Reputation: 332Reputation: 332Reputation: 332
Quote:
Originally Posted by jkobori View Post
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 */
}
 
Old 11-20-2012, 06:35 AM   #9
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,107

Rep: Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114
The part of my first post you need to understand:

Quote:
Originally Posted by johnsfine View Post
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 View Post
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.

Last edited by johnsfine; 11-20-2012 at 06:39 AM.
 
Old 11-20-2012, 06:46 AM   #10
jkobori
LQ Newbie
 
Registered: Sep 2012
Location: Budapest, Hungary
Distribution: Ubuntu Hardy Heron 8.04.3, Ubuntu x64 12.04
Posts: 19

Original Poster
Rep: Reputation: Disabled
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!
 
Old 11-20-2012, 06:51 AM   #11
dwhitney67
Senior Member
 
Registered: Jun 2006
Location: Maryland
Distribution: Kubuntu, Fedora, RHEL
Posts: 1,523

Rep: Reputation: 332Reputation: 332Reputation: 332Reputation: 332
Quote:
Originally Posted by jkobori View Post
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.

Last edited by dwhitney67; 11-20-2012 at 06:53 AM.
 
Old 11-20-2012, 07:08 AM   #12
jkobori
LQ Newbie
 
Registered: Sep 2012
Location: Budapest, Hungary
Distribution: Ubuntu Hardy Heron 8.04.3, Ubuntu x64 12.04
Posts: 19

Original Poster
Rep: Reputation: Disabled
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!
 
Old 11-20-2012, 07:44 AM   #13
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,107

Rep: Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114Reputation: 1114
Quote:
Originally Posted by jkobori View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Memory for crash kernel (0x0 to 0x0) notwithin permissible range casualzone Linux - Newbie 6 12-07-2011 07:30 PM
SSH Error taipei kernel: EDAC MC0: UE page 0x0, offset 0x0, grain 1073741824, row 7, ramesh_india2020 Linux - Newbie 1 09-23-2010 12:43 AM
[SOLVED] C - Segfault during malloc. Something to do with how I'm using the pointers.... golmschenk Programming 10 03-23-2010 09:55 PM
C - Malloc causing segfault golmschenk Programming 3 03-21-2010 03:21 PM
malloc/free and segfault - advanced question iTux Programming 3 12-10-2003 04:51 PM


All times are GMT -5. The time now is 07:01 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration