segmentation fault with fgets 
July 1st, 2009, 02:52 AM
| | Newbie | | Join Date: Feb 2009
Posts: 10
| |
Hi all, I'm completely stuck..
I have a program which reads integers (there are 65536 integers) from one file, and adds them into the Bloom filter. And then it reads another file (with a larger set of integers), and checks the existence of each element in the Bloom filter created in the first step. Here is the code. - #include <string>
-
#include <iostream>
-
#include <fstream>
-
#include "GeneralHashFunctions.h"
-
#include "falsetest.h"
-
using namespace std;
-
int main()
-
{
-
int outRes=0;
-
bfilter BF(BLOOMFILTER_NUMOFHASH, BLOOMFILTER_BITS_SIZE, &outRes);
-
FILE* pns;
-
pns = fopen ("pns" , "r");
-
unsigned int key;
-
char buffer[16];
-
while (!feof(pns)) {
-
fgets (buffer, 16, pns);
-
sscanf (buffer, "%u", &key);
-
BF.addmember((char*) &key, sizeof(key));
-
}
-
fclose(pns);
-
int counter = 0;
-
int counter2=0;
-
FILE* in_file;
-
in_file = fopen ("list" , "r");
-
setvbuf (in_file, NULL , _IOFBF , 4096 );
-
while (!feof(in_file)) {
-
counter2++;
-
fgets (buffer, 16, in_file);
-
sscanf (buffer, "%u", &key);
-
if (BF.isMember((char*) &key, sizeof(key)))
-
counter++;
-
}
-
BF.~bfilter();
-
cout<<"Positives= "<<counter<<"\n";
-
cout<<"Total= "<<counter2<<"\n";
-
cout<<"False positives= "<<counter-65535<<"\n";
-
fclose(in_file);
-
return 0;
-
}
when I compile and run it, GDB says: Quote:
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
| And here is the output of backtrace full: Quote:
(gdb) backtrace full
#0 0x00000000 in ?? ()
No symbol table info available.
#1 0xf7d3f144 in __uflow () from /lib/libc.so.6
No symbol table info available.
#2 0xf7d325b6 in _IO_getline_info () from /lib/libc.so.6
No symbol table info available.
#3 0xf7d32501 in _IO_getline () from /lib/libc.so.6
No symbol table info available.
#4 0xf7d313cd in fgets () from /lib/libc.so.6
No symbol table info available.
#5 0x08048d86 in main () at falsetest.cpp:16
outRes = 1
BF = {m_bf = 0x804d008 "", m_numHashFns = 3, m_logSize = 18, m_bfBitSize = 262144, m_initialized = 1, byteSize = 1, m_debug = 0}
pns = (FILE *) 0x804d018
key = 3029799107
buffer = "3029799107\n\0008\215╛Ъ"
counter = 134529012
counter2 = -5468808
in_file = (FILE *) 0x804a0d9
(gdb)
| One more thing, I found that it reads up to 371 integers from the first file ('pns), and then segfaults.
Could anyone help me with this problem?
|
July 1st, 2009, 10:15 AM
|  | Expert | | Join Date: Mar 2007
Posts: 10,634
Provided Answers: 2 | | | re: segmentation fault with fgets
Can you print out the value of your file stream 'pns' just after you've opened it (just after line #12) and compare it with the value printed by gdb after the crash? Both pointer values should be equal ...
kind regards,
Jos
|
July 1st, 2009, 11:00 PM
| | Expert | | Join Date: Mar 2008 Location: Naperville, Illinois U.S.
Posts: 804
Provided Answers: 3 | | | re: segmentation fault with fgets
Probably not causing the segmentation fault, but ...
what happens at lines 17 and/or 29 if the string can't be decoded by "%u"?
|
July 2nd, 2009, 03:34 AM
| | Newbie | | Join Date: Feb 2009
Posts: 10
| | | re: segmentation fault with fgets
Quote:
Originally Posted by JosAH  Can you print out the value of your file stream 'pns' just after you've opened it (just after line #12) and compare it with the value printed by gdb after the crash? Both pointer values should be equal ...
kind regards,
Jos | Thanks for reply... Actually, those two are not equal...The value printed by gdb, is on the line 372 of the file 'pns'. And there is nothing unusual in the file pns, just different integer numbers line-by-line.
Line 371: 3029799106
Line 372: 3029799107
Line 373: 3029799108
etc ........ Quote:
Originally Posted by donbock Probably not causing the segmentation fault, but ...
what happens at lines 17 and/or 29 if the string can't be decoded by "%u"? | No, I very much doubt that this is a problem... as I've already mentioned, the program segfaults on reading line 372 from file 'pns', and there is nothing unusual there.
What makes me wondered is that the second file -'in_file', is actually superset of the file 'pns', i.e. it has all integers that present in 'pns' plus some others. And if I give a few integers manually to the function 'addmember' (instead of reading them from 'pns'), and then check the loop in lines 26-32 runs perfectly!
|
July 2nd, 2009, 05:13 AM
| | Expert | | Join Date: Mar 2008 Location: Naperville, Illinois U.S.
Posts: 804
Provided Answers: 3 | | | re: segmentation fault with fgets
Quote:
Originally Posted by DrSchwartz Quote: |
Originally Posted by donbock Probably not causing the segmentation fault, but ...
what happens at lines 17 and/or 29 if the string can't be decoded by "%u"? | No, I very much doubt that this is a problem... as I've already mentioned, the program segfaults on reading line 372 from file 'pns', and there is nothing unusual there.
What makes me wondered is that the second file -'in_file', is actually superset of the file 'pns', i.e. it has all integers that present in 'pns' plus some others. And if I give a few integers manually to the function 'addmember' (instead of reading them from 'pns'), and then check the loop in lines 26-32 runs perfectly! | I just wanted to point that you still have a problem to solve after you resolve the segmentation faults. Your program relies on the input files being well-formed. That is not a good assumption to make in the real world. For example, suppose your input file contains "123O4" instead of "12304" (letter O instead of zero). Sscanf will cheerfully decode the unsigned integer value 123 without any hint that there was a problem. Real-world software design can spend more effort identifying and dealing with the corner cases than supporting the nominal functionality.
|
July 2nd, 2009, 05:30 AM
| | Newbie | | Join Date: Feb 2009
Posts: 10
| | | re: segmentation fault with fgets
Quote:
Originally Posted by donbock I just wanted to point that you still have a problem to solve after you resolve the segmentation faults. Your program relies on the input files being well-formed. That is not a good assumption to make in the real world. For example, suppose your input file contains "123O4" instead of "12304" (letter O instead of zero). Sscanf will cheerfully decode the unsigned integer value 123 without any hint that there was a problem. Real-world software design can spend more effort identifying and dealing with the corner cases than supporting the nominal functionality. | I absolutely share your point. But being aware that the 'pns' is generated by another program (written by myself) which writes explicitly integers to the file, I'm afraid the problem is not in this.
|
July 2nd, 2009, 07:07 AM
| | Expert | | Join Date: Mar 2007
Posts: 10,634
Provided Answers: 2 | | | re: segmentation fault with fgets
Quote:
Originally Posted by DrSchwartz Thanks for reply... Actually, those two are not equal...The value printed by gdb, is on the line 372 of the file 'pns'. And there is nothing unusual in the file pns, just different integer numbers line-by-line.
Line 371: 3029799106
Line 372: 3029799107
Line 373: 3029799108
etc ........
No, I very much doubt that this is a problem... as I've already mentioned, | No, I didn't mean the data content but the value of the pns FILE* itself, as in:
kind regards,
Jos
|  |
| | |  /bytes/about
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over 225,662 network members.
|
