New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intermittent CreateFile failure [CORE2507] #2919
Comments
Commented by: Claudio Valderrama C. (robocop) One thing we can do to track this is to add the file name to the error message, but only if C. |
Commented by: Stefan Schultze (stefanmg) We have a similar problem that might be related: We have a C# Windows Service that also uses Firebird Embedded 2.1.1. Our customers frequently report that this Windows Service sometimes doesn't come up with Windows. The error logged occurs when opening a database connection (isc_attach_database called internally) and also sais "operating system directive CreateFile failed". I am very sure that the database file is always there because we check the existence of the database file before trying to open it. One more thing that might be of interest is that this problem occurs way more often on newer Windows platforms (e.g. Windows Vista and Windows Server 2008). Never heard of the same problem from customers with Windows 2000 (there are quite a lot). |
Commented by: Richard Wesley (hawkfish) This is a screen shot from Tableau showing the calls to CreateFile during our server startup when the error occurred. Notice that all processes manage to create the lock file successfully except the first one. Even stranger, the initial create succeeds, but the process is told that the file does not exist about .8 ms later. Maybe this is some kind of timing bug in Windows? |
Modified by: Richard Wesley (hawkfish)Attachment: B24294a.png [ 11459 ] |
Commented by: Richard Wesley (hawkfish) This is the full sequence of events for all files. |
Modified by: Richard Wesley (hawkfish)Attachment: B24294b.png [ 11460 ] |
Commented by: Richard Wesley (hawkfish) This is a Firebird database containing the data in the first two images. |
Modified by: Richard Wesley (hawkfish)Attachment: B24294.TDE [ 11461 ] |
Commented by: Richard Wesley (hawkfish) This is the Tableau workbook used to generate the first two images. |
Modified by: Richard Wesley (hawkfish)Attachment: B24294.twbx [ 11462 ] |
Commented by: Richard Wesley (hawkfish) The call that is failing appears to be using the "Open" disposition instead of the "OpenIf" disposition. Thsi c an be seen by looking at the corresponding [Details] field for the failure record. |
Commented by: Richard Wesley (hawkfish) We suspect that the problem is that the lock file already exists. This is likely in a server startup scenario. The logic in isc_sync.cpp appears to not handle this case correctly in embedded mode because the file is opened with FILE_FLAG_DELETE_ON_CLOSE but sets file_exists to true - even though the CloseHandle call a few lines lower down will cause the file to be deleted and NOT exist! The workaround should be to delete the lock file on process startup. The process can generate the file name from the PID: fb_PID.lck in the user's temporary directory. |
Commented by: @hvlad This could happen only if TEMP directory already contains fb_pid.lck file. It is possible if sometime ago process with the same PID crashed and windows not removed file (opened with FILE_FLAG_DELETE_ON_CLOSE !). I think we should remove FILE_FLAG_DELETE_ON_CLOSE from the first call of CreateFile. Note, v2.5 have no this issue at all. |
Commented by: @hvlad It is easy to reproduce : 1. Start application, using embedded (isql_embed, for ex.), and don't connect to any database |
Commented by: @dyemanov No objections from me. At least, this is worth trying ;-) |
Modified by: @hvladassignee: Vlad Khorsun [ hvlad ] |
Modified by: @hvladstatus: Open [ 1 ] => Open [ 1 ] Fix Version: 2.1.4 [ 10361 ] Fix Version: 2.0.6 [ 10303 ] Planning Status: Unspecified => Considered for inclusion |
Modified by: @hvladVersion: 2.1.2 [ 10270 ] Version: 2.0.5 [ 10222 ] Version: 2.0.4 [ 10211 ] Version: 2.1.0 [ 10041 ] Version: 1.5.5 [ 10220 ] Version: 2.0.3 [ 10200 ] Version: 2.0.2 [ 10130 ] Version: 2.0.1 [ 10090 ] Version: 1.5.4 [ 10100 ] Version: 2.0.0 [ 10091 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovQA Status: No test |
Submitted by: Richard Wesley (hawkfish)
Attachments:
B24294a.png
B24294b.png
B24294.TDE
B24294.twbx
We have been seeing an intermittent problem with embedded Firebird
2.1.1 trying to open a local read-only database under Windows XP. The
database has been opened read-only by multiple processes and
periodically we get the following in our logs:
--- FB Error
---------------------------------------------------------------
File: db\FirebirdProtocol.cpp, Line: 2381
Status: 335544373
operating system directive CreateFile failed
-The system cannot find the file specified.
----------------------------------------------------------------------------
The line referenced is just calling isc_attach_database. Usually the
call succeeds and the file is definitely there.
The strange thing is that the Windows logging for the CreateFile call
shows two calls, one failing and then one succeeding, but Firebird
seems to not notice the second success!
After a little digging, it looks like the error is being generated in
ISC_map_file. I am suspicious now of gds__prefix_lock's ability to
come up with unique name in this situation...
Commits: f526717 f6e2152
The text was updated successfully, but these errors were encountered: