4

I am receiving a segfault from the second line of the following code: 

FILE *output = NULL;
output = fopen("./output2.txt", "w+");

I don't think it is some sort of corrupt memory error because when I change w+ to r. It runs with no segfault. ALSO, it appears to create the file right before it segfaults.

EDIT: turns out mrbatch is right

All my code for reference:

void writeFile(const char *header, int numRows, int numCols, int **grades, const char  *outFile)
{
    printf("writefile success\n");
    int i, j;
    FILE *output = NULL;
    output = fopen("./output2.txt", "w+");  // ERROR HERE (I was wrong, keep reading)
    printf("testestestsetsete\n\n\n");    //based off the commenters, this code 
                                          //IS reached but is never printed

    fprintf(output, "%s", *header);  //commenters stated error is here
                                     //*header should be header
    fprintf(output, "%d %d\n", numRows, numCols); //output the number or rows and columns at the second line

    //output each grades(scores) in the processed 2D array grades
    for(i = 0; i < numRows; i ++ ) {    //loop through all rows
        for( j = 0; j < numCols; j ++ ) //loop through all columns in the i row
        {   
            if( j < numCols - 1 )
                fprintf(output, "%d ", grades[i][j]);
            else
                fprintf(output, "%d\n", grades[i][j]);
            //printf("\"%d\" ", score);
        }
        //printf("\n");
    }

    fclose(output);

}

north.mister
  • 500
  • 1
  • 7
  • 24
  • The error is actually the first `fprintf` after your `fopen`. The `%s` format specifier expects a `char *` and you passed a `char` value (`*header`) which it tried to interpret as an address and caused a segfault. – lurker Mar 07 '14 at 03:29
  • I know it isn't that because I had a test printf in the code (I removed it before posting here) that was immediately after the fopen and before the fprintf's. – north.mister Mar 07 '14 at 03:30
  • 1
    Please show the test code with the `printf` and re-run the test. The `fopen` is fine, but the `fprintf` following most definitely isn't. Or better yet, comment out the `fprintf` that follows the `fopen` and see what happens. – lurker Mar 07 '14 at 03:32
  • 4
    A `printf` is usually a *bad* tool to use when debugging segfaults like this one (as a "did it get there" indicator). It's quite possible that the `printf` itself executed, but the output was not yet actually written to your terminal before the segafult (on the next line) occurred, and tore down the process. There is a lot of buffering that goes on between the call to `printf` and the output actually showing up. – Jonathon Reinhart Mar 07 '14 at 03:34
  • Ohh ok. I got into the (bad) habit of using print statements to aid in debugging before using Eclipse (first language was Java). – north.mister Mar 07 '14 at 03:35
  • `printf` statements are very good for debugging to a point. But they can be misleading in cases like this. You need other tests to verify. – lurker Mar 07 '14 at 03:36
  • 2
    Using `printf()` is fine as long as you (a) end the messages with a newline and (b) are not redirecting the output to a file or pipe. You can follow a `printf()` with `fflush(stdout)` to flush the pending output, too. – Jonathan Leffler Mar 07 '14 at 03:36
  • @user2489837: I wouldn't call using printf statements to debug necessarily bad - you just have to understand what its limitations are. Though I actually would have expected the newlines in the `printf()` call to force a flush before the crash since `stdout` isn't supposed to be fully buffered if it connected to the console. – Michael Burr Mar 07 '14 at 03:41

1 Answers1

5

The error is actually the first fprintf after your fopen.

fprintf(output, "%s", *header);  //output the same header

The %s format specifier expects a char * and you passed a char value (*header) which it tried to interpret as an address and caused a segfault.

lurker
  • 56,987
  • 9
  • 69
  • 103
  • Aha, turns out you were right. But how does that work. I had a test printf that was never reached between the fopen and the fprintf. How did the fprintf segfault it without hitting my test code?? – north.mister Mar 07 '14 at 03:32
  • @user2489837 See my comment above. The `printf` probably exectued, but the output just hadn't been written yet. – Jonathon Reinhart Mar 07 '14 at 03:34
  • 2
    @user2489837: Undefined behaviour is exactly that. – dreamlax Mar 07 '14 at 03:35