fopen Bug?

[wdolson]

I'm trying to track some problems in my code with trusty old log file method (looking at data patterns in a large data stream). I've done this many times before, but I'm getting an occasional error in my call to fprintf after fopen. The thing is that it opens and closes the file many times before triggering the error.

    FILE *fptr=0;
    char filename[256]="DebugFile.txt";
    DWORD err;

    fptr=fopen(filename,"a+");
    if(fptr==0)
    {
        err=GetLastError(); 
    }
...
    fprintf(fptr,"Some debug text\n");

When I put a break point on GetLastError and catch the last error, the code is 183, which according to MSDN is "Cannot create a file when that file already exists."

Is there some limit to the number of times you can open and close a file in a certain period of time and it throws a bogus error if you exceed it? That's the only thing I can think of here.

Bill

[Paul McKenzie]

I'm trying to track some problems in my code with trusty old log file method (looking at data patterns in a large data stream). I've done this many times before, but I'm getting an occasional error in my call to fprintf after fopen.

Post a complete example, so that we know exactly what you're doing, and we don't have to fill in code for ourselves. I see no fclose(), no loop giving us exactly how you're doing this, etc.

Secondly, fopen(), fclose(), etc. are C library function, GetLastError() is a Windows API function. This is not guaranteed to give you any correct results.

In general, you are not to assume that fopen(), fclose() somehow affects a Windows API function such as GetLastError(). CRT functions are CRT functions, Windows API functions are Windows API functions -- you cannot assume that one affects the other and vice-versa. If you want to use GetLastError, then use Windows API functions to open and close files, such as OpenFile().

Third, you realize that your code tags did not work?

Regards,

Paul McKenzie

[wdolson]

That's odd, I wonder why the code tags didn't work? I can't post the complete code because it's both proprietary (owned by my client) and there are lots of layers to it. The loop that eventually calls this function is two function calls back from this one.

I didn't realize that the GetLastError() function was unreliable in the error code return, though the error code I got was file related.

The code for the file is not much more than I posted, since it was temporary debug code, I haven't gone through any extensive checks to make sure the file was opening correctly, etc. This code will be gone long before a customer sees it. I'll flesh it out a little further:

FILE *fptr=0;
    char filename[256]="DebugFile.txt";
    DWORD err;

    fptr=fopen(filename,"a+");
    if(fptr==0)
    {
        err=GetLastError(); //Just put a breakpoint here to see what the error was
    }

    if(flag)
    {
      ret=CallFuntionThatDoesSomethingToTheData();
       fprintf(fptr,"Some debug text ret=0x%x\n",ret);
      if(fptr)
        fclose(fptr);
    }

I put code to create log files in all three layers of code. When down on this layer, there would be three file handles open at once because the first function calls the second which calls this one.

When I removed the file code from the top function call, this began working without errors. I also fixed the bug, so I don't need it anymore, but it appears there was something with three file handles open at once that was causing the problem. It only happened after 1000 or so calls, never at the start. Even though all three file handles were always open when it got down to this function call.

[MrViggy]

That's odd, I wonder why the code tags didn't work? I can't post the complete code because it's both proprietary (owned by my client) and there are lots of layers to it. The loop that eventually calls this function is two function calls back from this one.

I didn't realize that the GetLastError() function was unreliable in the error code return, though the error code I got was file related.

The code for the file is not much more than I posted, since it was temporary debug code, I haven't gone through any extensive checks to make sure the file was opening correctly, etc. This code will be gone long before a customer sees it. I'll flesh it out a little further:

FILE *fptr=0;
    char filename[256]="DebugFile.txt";
    DWORD err;

    fptr=fopen(filename,"a+");
    if(fptr==0)
    {
        err=GetLastError(); //Just put a breakpoint here to see what the error was
    }

    if(flag)
    {
      ret=CallFuntionThatDoesSomethingToTheData();
       fprintf(fptr,"Some debug text ret=0x%x\n",ret);
      if(fptr)
        fclose(fptr);
    }

I put code to create log files in all three layers of code. When down on this layer, there would be three file handles open at once because the first function calls the second which calls this one.

When I removed the file code from the top function call, this began working without errors. I also fixed the bug, so I don't need it anymore, but it appears there was something with three file handles open at once that was causing the problem. It only happened after 1000 or so calls, never at the start. Even though all three file handles were always open when it got down to this function call.

GetLastError is not unreliable, you are not using it in the correct context. You cannot use this function to check the state of a CRT function call.

Viggy

[Martin O]

You're checking for a valid fptr before logging errors or closing, but not before actually using the fptr with fprint. Very likely your problem has nothing at all to do with 3 opens at the same time or whatever. Its probably just lots more basic mistakes like what I just pointed out.

    char filename[256]="DebugFile.txt";

    FILE* fptr=fopen(filename,"a+");
    if(fptr==0)
    {
        // This is incorrect as mentioned above. DWORD err=GetLastError(); //Just put a breakpoint here to see what the error was
    }

    if(flag)
    {
      ret=CallFuntionThatDoesSomethingToTheData();
      if(fptr) {
        fprintf(fptr,"Some debug text ret=0x%x\n",ret);
        fclose(fptr);
      }
    }

[wdolson]

My comment about my ignorance of GetLastError being unreliable was in context of using it with fopen. I have used it many times in other situations and know it is reliable in the other contexts where I used it.

As for checking for fptr being good or not. I did move it inside the if(fptr), but that just covers up the problem that the file does not open about 0.1% of the time in the situation where I was using it. When I went up two levels and removed the code working with a log file on that level, the problem went away entirely without making any other changes to the code.

I am attempting to report the conditions under which the problem happens and trying to get some answers as to why. I did say in my first post that this was down and dirty debug code that was temporary.

I know how to write robust code, I've been writing C and C++ for over 20 years. This is quick debugging code just there to find the bug and then it was removed.

I have used these functions as well as the Windows API versions more times than I can count. I have not run into this particular problem before. Normally if a file doesn't open, it has a consistent pattern behind why it doesn't open. Opening 999 times fine and then suddenly deciding not to open is a pattern I haven't seen before (except in the case where there was more than one program accessing a file, which was not happening in this case.)

[Martin O]

20 years of programming experience & you're still blaming the compiler or os ('fopen bug?') when your program has problems? Wow.

[Paul McKenzie]

I am attempting to report the conditions under which the problem happens and trying to get some answers as to why.

Then you need to do a better job of posting examples than what you did here.

Anytime you claim a bug, you need to post a complete, small example of reproducing the bug. If you're reporting this to Microsoft, and even if not, reporting it to some third-party, this is what they will ask of you. So far, you didn't provide it here, only a snippet here and there, which does not count as a full example, and so does not prove anything to us.

Similaraly, a multi-thousand line, multi-project program isn't going to be helpful to those looking at the problem, since who knows what other things may be going on in your program that could affect what's happening. I have experience in this, and my company has made it a requirement that any problems reported with our API must be accommodated by a simple program demonstrating the problem.

If you wrote a simple main() program, and inside this program wrote a loop that executed 10,000 times calling fopen() and fclose(), would you see the issue? That is what I'm referring to -- a complete example, not needing any changes, that if we copied and pasted that code in the compiler, compiled it, ran it, we can say "by gosh, you're right", or "I see no problem".

Regards,

Paul McKenzie

[Martin O]

So far, you didn't provide it here, only a snippet here and there...

And the snippet had bugs. And all we have is an assurance that 'oh, well I didn't make that same mistake in the real code that I didn't show you'.

[ovidiucucu]

I didn't realize that the GetLastError() function was unreliable in the error code return, though the error code I got was file related.

That's just a simple coincidence.
As already stated above, the CRT functions do not set the value returned by GetLastError WinAPI function.
Instead, some CRT functions set errno value.

[Martin O]

Sorry about the harsh words. I tend to overreact when programmers blame the compiler or os.

I thought of one possibility -- your logging function is getting called from multiple threads maybe? Try adding the current thread id to the logging message. (I forget how to get it, something like GetCurrentThreadId()). Also, to help deal with the behavior of 'undefined-behavior', add asserts thru-out the code. A lot of times, the real bug is in a different area than it appears to be. The code with the actual bug runs fine because of 'undefined-behavior'. An assert can possibly catch a bug that would otherwise go unnoticed.