views:

180

answers:

3

Hi

I have a VC++ application and in my application i have some basic file operations.

Below is the defaulting code

CStdioFile cFile;
CFileException e;
CString sReport;
CString sHtmlfile = "testreport.html"
OutputDebugString((sHtmlfile));
if (!cFile.Open(sHtmlfile,CFile::modeCreate | CFile::modeWrite, &e ))
{
}

The problem is my application executes this piece of code every few minutes. and it works fine.

After several runs of the code the cFile.Open() function fails. I tried to get the error message

TCHAR szError[1024];
e.GetErrorMessage(szError,1024);
OutputDebugString((szError));

The irony is the szError error message is "No error occured".

This again works once i restart my application. Any idea why this occurs.

Thanks in advance.

+1  A: 

Maube you forget to close your file and it come out of file descriptors. They are all closed when you quit your application, then you can run it again. Check if your files are closed or not.

OK. If this is not the above case, what could it be ? You get the error message from cFile.Open, hence we can believe it's accurate.

I'm not sure what would happen if another file of the same name is already open by the current process, or if you try to open a file with a strange name, like empty string. To sort these out you can also print the name of the file you are opening with the error (and also trace the cases where no error occurs).

kriss
The CFile.Close is called at the end of this function. So that must not be the problem
ckv
@viswanathan: This is only true if the `cFile.Close()` is actually executed. If you have to do this manually, there's a good chance that an exception prevents it from execution. (Or an early `return` for all we know. We haven't seen your code.) That's what RAII is for.
sbi
Well it can be rest assured that the CFile.Close() actually executes. There are no return statements prior to that. I have verified that by stepping through the code.
ckv
@viswanathan: I have learned the hard way not to assume anything unless proven. Have you checked whether the file is already opened when the opening failed using some of the tools available? (What's its name? FileMonitor?)
sbi
I am yet to probe further on that. But if the exception says "No Error Occured" it got to mean something. I couldnt find any relevant documentation regarding this error in MSDN. Still working out with the code
ckv
@viswanathan: Note that the message "No error occurred" could also be an error in itself. This sounds like what `GetLastError()` reports. If the library code calls any other API between the failing one and calling `GetLastError()`, the message is misleading.
sbi
As you can see from the code above i dont call any other API between the failing one and calling GetLastError().
ckv
@viswanathan: Indeed, but not knowing MFC, I wouldn't know about `CStdioFile::Open()`.
sbi
+2  A: 

Do you have multiple instances running? I suggest you use Process Explorer when the error occurs to see if any other handles to the said file exist.

And GetLastError will report the error reported by the last API function. If there were any other API calls between the failing API call and the call to GetLastError, then the last error value is overwritten. (As @sbi has already pointed out in the comments.)

Vulcan Eager
No i dont have multiple instances running. Let me see if i can use process explorer.Yes true but i dont call any other API so that the last error value cant overwrite. You can refer the code above.
ckv
There could be other API calls within the `CStdioFile::Open` class. The source for 'CStdioFile' comes along with MFC... might help to have a look (though experience says otherwise).
Vulcan Eager
Yes thats the whole point.
ckv
What exactly do you do with the file once it opens successfully?
Vulcan Eager
Once i open the file i fill it with many contains something like a report of some data and then i mail the file to few email addresses. And finally of course i close the file.
ckv
I got the process explorer installed. Can you explain how i can effectively make use of it to find out the file problem
ckv
THe process explorer just shows the private bytes and working set. How is this going to help me.
ckv
"Find > Find Handle or DLL"
Vulcan Eager
Sorry but i am not quite sure what you want me to search. I understand the Find handle but cant make much out of it. If you can explain it in more detail it would be of great help
ckv
Search for `testreport.html`. This should give you a list of all open file handles to the said file. Also, lists the name and PID of the process which has the file open.
Vulcan Eager
Ok Thanks i shall run the same and let u know the results. It will take atleast 6 hours for me to reproduce the issue.
ckv
Well the issue was reproduced but i couldnt find any handles to the file names in the process explorer.
ckv
Well the issue was reproduced but i couldnt find any handles to the file names in the process explorer. And this issue comes like after the service goes through this code for around 500 times and each of the 500 times i get the email with the corresponding html file and then it just stops because it fails in CFile::Open()
ckv
That's tricky. I was thinking that you could put a breakpoint somewhere and then then search for handles when the call to Open fails. I am almost out of ideas here. Last shots: try disabling your anti-virus program, try using a different disk.
Vulcan Eager
Yes i shall probably try that. Actually i wanted to add that this does not happen in all machines.
ckv
Well i just found that the files are getting created with size 0KB but i am not able to use them as the exception still occurs. Could this be a handle problem.
ckv
Looks like a handle problem at first sight. But since you mentioned that this does not happen on all machines, it could be other things...
Vulcan Eager
+1  A: 

You are using C++. Your error could be completely somewhere else. I've had a pointer bug that resulted in clean code coughing up an error.

Have you tried building in release mode?

I would suggest trying to step through and perhaps narrow down where your error appears.

PLG
I have stepped through the code and i could find out that it failed exactly in CFile::Open(). When i run the same in release build also i can reproduce the issue with same results.What more should i try?
ckv
try adding NULL as the third parameter for Open() and surround the function call in a try/catch section catching CFileException. I assume this from the docs, "While the CFile constructor will throw an exception in an error condition, Open will return FALSE for error conditions." I also see that you most likely copied the example from the Open docs. On definite distinction is that they use a char* and you are using CString. Are you sure that CString is casting to LPCTSTR correctly?
PLG
Another suggestion which hinges on my previous post is... to check to see if the address space of your CString is not being overwritten at some point. That would be the sign that your error is wild pointer related.
PLG
Well i just found that the files are getting created with size 0KB but i am not able to use them as the exception still occurs. Could this be a handle problem
ckv
If that is the case, then my first guess would be that 'CFile::modeWrite' is failing. Is the close() not happening fast enough so that you get a contention error? Perhaps add a counter to the name of the file and see if the error persists. So your files will be testreport1.html, testreport2.html, etc...Why are you opening and closing the file rapidly anyways? If you keep writing to the same file over and over, then why not have an instance variable that holds the open file and closes it after you are completely done with it?
PLG
For your information i dont open the same file over and over again. I open different files with different file names just for a sample i wrote that code. And it is not really that fast everyhting goes in sequential order only until one file is closed the other wont open.
ckv