segmentation fault with fgets

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • DrSchwartz
    New Member
    • Feb 2009
    • 10

    segmentation fault with fgets

    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.
    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_inf o () 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:1 6
    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\0 008\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
    Recognized Expert MVP
    • Mar 2007
    • 11453

    #2
    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

    Comment

    • donbock
      Recognized Expert Top Contributor
      • Mar 2008
      • 2427

      #3
      Probably not causing the segmentation fault, but ...
      what happens at lines 17 and/or 29 if the string can't be decoded by "%u"?

      Comment

      • DrSchwartz
        New Member
        • Feb 2009
        • 10

        #4
        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 ........
        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!

        Comment

        • donbock
          Recognized Expert Top Contributor
          • Mar 2008
          • 2427

          #5
          Originally posted by DrSchwartz
          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.

          Comment

          • DrSchwartz
            New Member
            • Feb 2009
            • 10

            #6
            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.

            Comment

            • JosAH
              Recognized Expert MVP
              • Mar 2007
              • 11453

              #7
              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:

              Code:
              pns = (FILE *) 0x804d018
              kind regards,

              Jos

              Comment

              Working...