fopen(), crashing, memory allocation?

[Kat B]

I am seriously at a complete loss as to what I am experiencing.

If I write a small program, with this line in it, it works fine:

FILE * fp = fopen("test.txt", "a+");

However, when I add that one line into a pre-existing project and try to run it (it successfully compiles), I come up with this error:

The Instruction at "07c9369da" referenced memory at "0x00000000". The memory could not be "read". Click on OK to terminate the program.

I have narrowed it down to that one line. Is there something wrong with that one line, or is it something else? What should I be looking at to find the source of the problem?

(I really am demoralised and desperate at this stage).

Is it a general memory allocation problem and it just so happens that it rears its ugly head in fopen()? Shouldn't then fopen() be retuning NULL?

[Moooce]

This tends to happen when there's some memory corruption. Can you post some of the code before the fopen? If you're working with an array, maybe there's a buffer overrun happening.

[Kat B]

There are many possible improvements to this code. However, at the moment, I'm just focusing on the fopen() problem. The "test.txt" was to check whether or not it was my string that was causing the problem. It isn't the string. Could the problem be elsewhere in the project? Then why does the error happen at fopen()?

The offending code:

    int result = 0;

    char filepattern[1000];// = new char[1000];
    strcpy(filepattern, portpath); // portpath is less than 5 char string
    strcat(filepattern, "*.TCR");

   // int length = strlen(filepattern);
   // filepattern[length] = '\0';


    WIN32_FIND_DATA find_data;
    HANDLE  file = FindFirstFile(filepattern, &find_data);


for (int i = 0; i < n; i++){
    if (file!= INVALID_HANDLE_VALUE) {
        FindNextFile(file, &find_data);
    }
}


    if (file!= INVALID_HANDLE_VALUE) {

        char charFileName[1000];// = new char[1000];

        strcpy(charFileName, portpath);
        strcat(charFileName, (find_data).cFileName); // known to be less than 11 char in length

       // int nameLength = strlen(charFileName);
       // charFileName[nameLength] = '\0';


        //char * pcharFileName = &charFileName[0];

        FILE * fp = fopen("test.txt", "a+"); // <-- source of problems
/*

        if (fp == NULL) {
            return -1;
        }

        else {

            fseek(fp, 0, SEEK_END);
            result = ftell(fp);

            fclose(fp);
        }
*/

    } // end if correct conditions

  FindClose(file);

    return result;

If I blank out all lines, leaving just this shell, I get the same error:

    int result = 0;

            FILE * fp = fopen("test.txt", "a+");


    return result;

However, if I comment out FILE * fp = fopen("test.txt", "a+"); then no error is thrown.


If I replace FILE * fp = fopen("test.txt", "a+"); with char * test = "test"; then it works fine.

However, if I instead replace FILE * fp = fopen("test.txt", "a+"); with char * test = new char[1000]; then I get a different error about a pointer problem.

[helios]

Is this ALL the code in the program? If not, then like Mooce said, you probably have some memory corruption. Those are hard to debug, because once memory is corrupted, the program could crash literally anywhere, and therefore, the function where the program did crash may have nothing to do with the function that has the bug.

[Kat B]

Memory allocations are more common with arrays? So check my arrays?

Sorry, that should have read, memory corruptions are more common with arrays?

@helios, it isn't *all* the code the in program as that is not what Mooce asked for. He asked for 'some' and got it. All of the code is too much.

[helios]

All of the code is too much.

Sounds like you'll have a very fun week.

[Kat B]

Actually, I think I found it. I was only calling six small methods when I got it, so I went back and checked and think I found something I had accidently not cleaned up. After cleaning it up, the error disappeared.

Mooce's comment about the memory corruption was very useful :)

[kbw]

IS there are reason you're using char arrays rather std::string for your strings? On a Windows box with it wonderfully descriptive file and directory names, you can easily excede 999 characters.

[Moooce]

Good to know you found it, it's a trikky one when it happens. The other problem to look out for with fopen() sometimes is if you fclose() a file more than once. I've had this happen where I've called fclose() on a file that was already closed, and the next call to fopen() failed in the same way as you had, even though the file pointer was a different one, so I understand how perplexed you felt!

[kempofighter]

If you only think that you found it then you may not have. You can change a few things that are unrelated to the problem and it will simply change the problem. It is important to understand root cause. I agree with KBW by the way. Did you debug and ensure that there is no problem with your strcpy and strcat function calls? Wouldn't it be better to just use the std::string and its interface for string manipulations so that there is no concern about array overflow or non-null terminated char arrays? I have no idea what the arrays are set to but those c-run time functions will cause all kinds of problems if your character arrays are not properly null terminated or are too large.

[Kat B]

@kbw There is a long and boring story behind the decision for the char arrays. I am aware that there are many possible improvements the code :)

@Moooce It is always good to walk away from a problem and get a hint from someone else :)

@Kempofighter I am aware that I may not have solved that problem. That is why I used the word, 'think'. However, since it was only six small methods and I went back over them with a fine tooth comb, I'm confident I found the error :) I did go back and check all my c-style strings. That was the first thing I did, and the second, third, fifth, six, seventh, nine, tenth and so on ;)