Issue Details (XML | Word | Printable)

Key: CORE-5980
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Svend Meyland Nicolaisen
Votes: 0
Watchers: 6

If you were logged in you would be able to see more operations.
Firebird Core

Firebird crashes due to concurrent operations with expression indices

Created: 07/Jan/19 09:28 AM   Updated: 22/Jan/19 06:39 PM
Component/s: Engine
Affects Version/s: 2.5.6, 2.5.8
Fix Version/s: 4.0 Beta 1, 2.5.9, 3.0.5

File Attachments: None
Image Attachments:

1. Capture.PNG
(88 kB)
Environment: Windows Server 2012 R2

QA Status: No test

 Description  « Hide
We have an application which creates a firebird database from scratch, populating it with a large number of tables, views, indices, stored procedures etc. On servers that runs on hardware that are slower than production systems normally are, the Firebird server crashes every time our application tires to create the database. The statement that apparently crashes the server does not crash the server when executed at any other time, so I am thinking it is a result of some or all of the previous statements. Also - the server does not crash (every time - I might have seen it once or twice) on faster systems, which makes me think that is some sort of race condition in the server.

I have tried to connect WinDbg to the server, and an access violation repeatedly begins to occur several statements before the fatal statement. All of the statements (except for the fatal one) however executes as expected. Several access violations occur before the server crashes (too many to count). I have attached a screen dump of the call stack when one of the access violations occur.

I am experiencing the problem with Firebird 64 bit server version 2.5.6 and 2.5.8 running as SuperServer on Windows. I haven't tested with other versions of Firebird.

Our software works perfectly on all our production systems, but these crashes worries me a bit, as it indicates that there is some problem that could appear any time at any system.

I don't know if this is a problem that the Firebird developer group will look into, or if the 2.5 version is permanently closed. If it is, I will gladly help with further information.

Kind regards,

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 07/Jan/19 10:40 AM
Reproducible test case will be ideal to have.
Or, at least, full memory dump when first AV hapens.

Svend Meyland Nicolaisen added a comment - 07/Jan/19 11:07 AM
Hi Vlad
A zipped full memory dump are larger than 10 MB. How can I upload that?

Vlad Khorsun added a comment - 07/Jan/19 12:28 PM
Upload to any filesharing service and send me the url, please ( for example)

Also, could you try to run script using current snapshot build of 2.5.9 ?

Svend Meyland Nicolaisen added a comment - 07/Jan/19 12:35 PM
Here you go:

I will try to try 2.5.9.

Svend Meyland Nicolaisen added a comment - 07/Jan/19 12:37 PM
I think there is problems with the download page for the snapshot builds. I am not able to download any of them.

Svend Meyland Nicolaisen added a comment - 07/Jan/19 12:40 PM
I have a little correction to my description of the problem. It is the last statement that initiates the access violations which results in a server crash. All other statements executes successfully with no access violations.

Vlad Khorsun added a comment - 07/Jan/19 12:45 PM
I also see the problem with snapshot's host.
I'll inform you when it gets fixed.

Vlad Khorsun added a comment - 07/Jan/19 09:08 PM
Two things FYI:
- i downloaded your dump and investigating it
- snapshots could be downloaded now

Svend Meyland Nicolaisen added a comment - 08/Jan/19 12:03 AM

I am experiencing the same issues with the snapshot build.

Vlad Khorsun added a comment - 08/Jan/19 09:26 PM
The fix is committed, please try next snapshot build (after

Svend Meyland Nicolaisen added a comment - 09/Jan/19 09:58 AM
Fantastic! My application runs without problems with the snapshot build.

Vlad Khorsun added a comment - 09/Jan/19 02:23 PM
Thanks for confirmation

Omacht András added a comment - 10/Jan/19 09:01 AM
Hi Vlad!
Can you explain briefly what was the cause of the error?

Vlad Khorsun added a comment - 10/Jan/19 09:22 AM
The issue is related with expression indices and shared metadata cache in SuperServer.

It could happens when internal request, used to calculate index key, saves pointer to the attachment which first load and compiles this request.
Then this attachment is released and some other attachment going to recompile index expression. When old request is released,
"its" attachment (if present) is accessed - but that attachment was already released some time ago.
The bug is that pointer to the attachment at (shared) request should not be kept after execution of request.
The same is true for procedure's and trigger's shared requests but there was no such bug.

Hope it helps ;)

Omacht András added a comment - 12/Jan/19 10:32 AM
Yes Vlad, thanks!