segmentation fault with fgets

[DrSchwartz]

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:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()

And here is the output of backtrace full:

(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?

[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

[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"?

[DrSchwartz]

@JosAH
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 ........
@donbock
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!

[donbock]

@DrSchwartz
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.

[DrSchwartz]

@donbock
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.

[JosAH]

@DrSchwartz
No, I didn't mean the data content but the value of the pns FILE* itself, as in:

pns = (FILE *) 0x804d018
 

kind regards,

Jos