Fgets causing segmentation fault at eof

Question

I looked up other people having this issue, but it seems that their problem was due to not having the correct size array or using an invalid pointer.

Here is the relevant code i'm using.

#include <stdio.h>
void Printcommands()
{
    FILE * commandfile;
    char str[256];
    if ((commandfile = fopen("commands.txt", "r")) != 0) //Open the commands file in read mode
    {
        while (fgets(str, 256, commandfile) != 0) //While there are still more commands to be processed in the script file
        {
          printf("Content: %s\n", str); //Print line from file
        }
        fclose(commandfile); //Close command file
        return; //return
    }
    else //Issue opening file
    {
        perror("Error opening commands.txt: "); //Print out error
        return;
    }
}


int main(int argc, char **argv)
{
  Printcommands();
  return 0;
}

Here is the contents of the commands.txt file

/bin/ls
asdf
asd

Here is my output

Content: /bin/ls

Content: asdf

Content: asd

Segmentation fault (core dumped)

Any idea what could be causing the segmentation fault? Thanks

It looks alright to me, and it also works when I run it. Are you really sure that the code you posted here is the same that you're running? (In other words, have you recompiled properly, running the right output file, &c&c&c.?) — Dolda2000, Apr 21 '16 at 12:49
printf() may segfault if str is not null-terminated. http://stackoverflow.com/questions/4361109/printf-of-char-gets-segmentation-fault — Arvo, Apr 21 '16 at 12:49
@Arvo: While that is true, `fgets` normally does NUL-terminate its output. — Dolda2000, Apr 21 '16 at 12:50
Should be `while (fgets(str, 256, commandfile) != NULL)` faopne also — LPs, Apr 21 '16 at 12:50
@Arvo [`man fgets`](http://linux.die.net/man/3/fgets): "A terminating null byte (aq\0aq) is stored after the last character in the buffer." — Siguza, Apr 21 '16 at 12:50
@LPs: While perhaps nicer, `NULL` and `0` are synonymous in C. — Dolda2000, Apr 21 '16 at 12:51
@Arvo - if `fgets()` returns non-`NULL`, the string will be terminated with a `'\0'` character. I'm wondering if `fgets(str, 256, commandfile) != 0` is the problem? An old compiler that's not treating a literal `0` as a `NULL` pointer? — Andrew Henle, Apr 21 '16 at 12:51
@LPs: http://stackoverflow.com/questions/1296843/what-is-the-difference-between-null-0-and-0 — Dolda2000, Apr 21 '16 at 12:52
@Dolda2000 *While perhaps nicer, `NULL` and `0` are synonymous in C* Not until C99, IIRC. — Andrew Henle, Apr 21 '16 at 12:52
@AndrewHenle: Even if the unlikely case is true that he's using a compiler that does not strictly equate `NULL` and `0`, I find it even more unlikely that he'd actually be running this on an architecture where they are also, in practice, different. That seems like a stretch of the imagination. — Dolda2000, Apr 21 '16 at 12:54
@Dolda2000 I am sure that it is the same code. It works fine on my machine which is Windows 7 64 bit using Visual Studios to compile/execute, however when using putty and connecting to the school's server, I get a segmentation fault when running the program using their compiler with the same commands.txt file. — user2980207, Apr 21 '16 at 12:54
@user2980207: Please use a debugger, such as `gdb`, to find out exactly where it crashes. Also, please provide information on what platform and compiler you're using on the school's server. — Dolda2000, Apr 21 '16 at 12:55
@user2980207: What OS and compiler is your school's server using? Did you compile with full warnings? — EOF, Apr 21 '16 at 12:56
@user2980207 Is that the entirely of the source code? No `#include `? — Andrew Henle, Apr 21 '16 at 12:56
@Siguza - *Vote to close as not reproducible.* I think the reproducibility is going to be platform-dependent. I'm guessing the OP left off the required header files. — Andrew Henle, Apr 21 '16 at 13:00
@AndrewHenle The only additional line that I did not include was the #include I must have missed it when copy and pasting. I am using gcc to compile the program. The server has gone down since I have posted this, so I have to wait until they get their issues resolved and then I will debug the program through their server to see where exactly it is crashing. — user2980207, Apr 21 '16 at 13:02
@Dolda2000 Ok, but why don't code it as manual says? _return s on success, and NULL on error_. BTW I wtote **should be** — LPs, Apr 21 '16 at 13:04
If you cannot run it with a debugger, put lots of printfs at different locations in your program, so you can find out _where exactly_ the crash happens. — Jabberwocky, Apr 21 '16 at 13:07
@LPs: Yes, as I said, it's nicer; it just shouldn't be the cause of the segfault. — Dolda2000, Apr 21 '16 at 13:10
@AndrewHenle C99 did not change `NULL`. it has always (well, since C89) been either `(void *)0` or `0` at the implementation's discretion, where `0` may be an integer constant expression evaluating to `0` — M.M, Apr 21 '16 at 13:10
@Dolda2000 Last comment: it is why I commented and not answered. Bye. — LPs, Apr 21 '16 at 13:10
@AndrewHenle comparing pointer to integer performs conversion of the integer to pointer. C has always worked this way (even before C89) — M.M, Apr 21 '16 at 13:12
Looks like the issue is not with `fgets()` as the program succesffuly reads and prints all 3 input lines. It may be `fclose()` or something in `main()` — pmg, Apr 21 '16 at 13:13
Perhaps the code was compiled with `-Dreturn="fgetc(commandfile)"` — M.M, Apr 21 '16 at 13:15
@M.M *comparing pointer to integer performs conversion of the integer to pointer. C has always worked this way (even before C89)* But that doesn't mean a literal `0` had to be a `NULL` pointer. — Andrew Henle, Apr 21 '16 at 13:16
Minor: Suggest `void Printcommands()` --> `void Printcommands(void)`. — chux - Reinstate Monica, Apr 21 '16 at 22:06

Fgets causing segmentation fault at eof

0 Answers0