Connecting Tech Pros Worldwide Forums | Help | Site Map

segmentation fault with fgets

Newbie
 
Join Date: Feb 2009
Posts: 10
#1: Jul 1 '09
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.
Expand|Select|Wrap|Line Numbers
  1. #include <string>
  2. #include <iostream>
  3. #include <fstream>
  4. #include "GeneralHashFunctions.h"
  5. #include "falsetest.h"
  6. using namespace std;
  7. int main()
  8. {
  9. int outRes=0;
  10. bfilter BF(BLOOMFILTER_NUMOFHASH, BLOOMFILTER_BITS_SIZE, &outRes);
  11. FILE* pns;
  12. pns = fopen ("pns" , "r");
  13. unsigned int key;
  14. char buffer[16];
  15. while (!feof(pns)) {
  16.         fgets (buffer, 16, pns);
  17.         sscanf (buffer, "%u", &key);
  18.         BF.addmember((char*) &key, sizeof(key));
  19. }
  20. fclose(pns);
  21. int counter = 0;
  22. int counter2=0;
  23. FILE* in_file;
  24. in_file = fopen ("list" , "r");
  25. setvbuf (in_file, NULL , _IOFBF , 4096 );
  26. while (!feof(in_file)) {
  27.         counter2++;
  28.         fgets (buffer, 16, in_file);
  29.         sscanf (buffer, "%u", &key);
  30.         if (BF.isMember((char*) &key, sizeof(key)))
  31.                 counter++;
  32. }
  33. BF.~bfilter();
  34. cout<<"Positives= "<<counter<<"\n";
  35. cout<<"Total= "<<counter2<<"\n";
  36. cout<<"False positives= "<<counter-65535<<"\n";
  37. fclose(in_file);
  38. return 0;
  39. }
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?

JosAH's Avatar
Expert
 
Join Date: Mar 2007
Posts: 10,611
#2: Jul 1 '09

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
Expert
 
Join Date: Mar 2008
Location: Naperville, Illinois U.S.
Posts: 831
#3: Jul 1 '09

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"?
Newbie
 
Join Date: Feb 2009
Posts: 10
#4: Jul 2 '09

re: segmentation fault with fgets


Quote:

Originally Posted by JosAH View Post

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 View Post

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!
Expert
 
Join Date: Mar 2008
Location: Naperville, Illinois U.S.
Posts: 831
#5: Jul 2 '09

re: segmentation fault with fgets


Quote:

Originally Posted by DrSchwartz View Post

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.
Newbie
 
Join Date: Feb 2009
Posts: 10
#6: Jul 2 '09

re: segmentation fault with fgets


Quote:

Originally Posted by donbock View Post

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.
JosAH's Avatar
Expert
 
Join Date: Mar 2007
Posts: 10,611
#7: Jul 2 '09

re: segmentation fault with fgets


Quote:

Originally Posted by DrSchwartz View Post

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:

Expand|Select|Wrap|Line Numbers
  1. pns = (FILE *) 0x804d018
  2.  
kind regards,

Jos
Reply

Tags
fgets segmentation bloom