Skip to content
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

Closed
firebird-automations opened this issue Jun 12, 2009 · 21 comments
Closed

Intermittent CreateFile failure [CORE2507] #2919

firebird-automations opened this issue Jun 12, 2009 · 21 comments

Comments

@firebird-automations
Copy link
Collaborator

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

@firebird-automations
Copy link
Collaborator Author

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
- it's embedded
- you're dba
- you're db owner.

C.

@firebird-automations
Copy link
Collaborator Author

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).

@firebird-automations
Copy link
Collaborator Author

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?

@firebird-automations
Copy link
Collaborator Author

Modified by: Richard Wesley (hawkfish)

Attachment: B24294a.png [ 11459 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Richard Wesley (hawkfish)

This is the full sequence of events for all files.

@firebird-automations
Copy link
Collaborator Author

Modified by: Richard Wesley (hawkfish)

Attachment: B24294b.png [ 11460 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Richard Wesley (hawkfish)

This is a Firebird database containing the data in the first two images.

@firebird-automations
Copy link
Collaborator Author

Modified by: Richard Wesley (hawkfish)

Attachment: B24294.TDE [ 11461 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Richard Wesley (hawkfish)

This is the Tableau workbook used to generate the first two images.
Free reader is available at <http://www.tableausoftware.com/products/reader-download>.

@firebird-automations
Copy link
Collaborator Author

Modified by: Richard Wesley (hawkfish)

Attachment: B24294.twbx [ 11462 ]

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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.

@firebird-automations
Copy link
Collaborator Author

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.
Objections ?

Note, v2.5 have no this issue at all.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

It is easy to reproduce :

1. Start application, using embedded (isql_embed, for ex.), and don't connect to any database
2. Create file in %TEMP% with name fb_PID.lck, where PID is process id of application above
3. Connect to any database by application above

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

No objections from me. At least, this is worth trying ;-)

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Open [ 1 ]

Fix Version: 2.1.4 [ 10361 ]

Fix Version: 2.0.6 [ 10303 ]

Planning Status: Unspecified => Considered for inclusion

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

Version: 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 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment