Fatal lock manager error: Process disappeared in LockManager::acquire_shmem, errno: 0

[Dany40]

Hello;

I am getting this error; 3 times in 3 different VMs in the last 7 days:

Fatal lock manager error: Process disappeared in LockManager::acquire_shmem, errno: 0

And on the client I am getting this errors:

REMOTE INTERFACE/gds__detach: Unsuccessful detach from database.
Uncommitted work may have been lost.
Error writing data to the connection.

INET/inet_error: send errno = 10054, server host = LOCALHOST, address = 127.0.0.1/3050

Machines are all Windows Server 2012 R2. And Firebird is 5.0.3 64 bit.

Here you can get a dump for the firebird service:

 https://drive.google.com/file/d/139cpgHN8bJzJ3O3m0ewn83wFapUHnDmU/view?usp=sharing

What can it be the problem?

Thank you!

[Vlad Khorsun]

  This is not a crash dump, that should be produced after "Fatal lock manager error" message was written

into firebird.log. This dump was produced with idle server process with 59 databases connected.

What can it be the problem?

  Looks like some bad race condition when last connection to the some database is gone and at the same time

new connection arrives. Reproducible test case should help.

Regards,

Vlad

[Dany40]

That's right Vlad, and this is because all continues running and we noticed the problem around 6 ours later. We can't understand what is going on, as the " Fatal lock manager error " is writted on the firebird log but the Firerbird server service continues to work; but afther that fatal error occurs, at the client side we start to get a firebird.log with this errors:

REMOTE INTERFACE/gds__detach: Unsuccessful detach from database.
Uncommitted work may have been lost.
Error writing data to the connection.

INET/inet_error: send errno = 10054, server host = LOCALHOST, address = 127.0.0.1/3050

Maybe this errors on the client side are writted every  time a conection finishes, but we are not sure.

Also we don't see consequences in the clients that are connected and working, the only symptoms are what we see on both firebird logs.

This problem appeared 3 times, each one in 3 different VM, on the same tenant. On each VM (16 GB RAM - 8 CPU) I have a Firebird 5.0.3 server with 130 databases (can that be a problem?), and never are more than 270 users connected. CPU resource use never goes over 15% in use and RAM never goes over 30% in use. I guess the problem is something on the VM configuration because is started after the provider did some changes on tenant. I try to understand the error to find out what produces it, but I am 99% sure this is not a Firebird problem.

Regards!

[Dany40]

Hello! Is it posible that this parameter can help me to fix this situation?

# ----------------------------
# Determines the number of seconds that the lock manager will wait after a
# conflict has been encountered before purging locks from dead processes
# and doing an extra deadlock scan cycle. The engine detects deadlocks instantly
# in all normal cases, so this value affects things only if something goes
# wrong. Setting it too low may degrade system performance.
#
# Per-database configurable.
#
# Type: integer
#
#DeadlockTimeout = 10

Thank you!

[Vlad Khorsun]

Hello! Is it posible that this parameter can help me to fix this situation?

# ----------------------------
# Determines the number of seconds that the lock manager will wait after a
# conflict has been encountered before purging locks from dead processes
# and doing an extra deadlock scan cycle. The engine detects deadlocks instantly
# in all normal cases, so this value affects things only if something goes
# wrong. Setting it too low may degrade system performance.
#
# Per-database configurable.
#
# Type: integer
#
#DeadlockTimeout = 10

  No. 

  Provide me with memory dump of crashed process. Use WER or SysInternal's procdump utility 

to collect crash dumps on Windows.

Regards,

Vlad

[Vlad Khorsun]

  Provide me with memory dump of crashed process. Use WER or SysInternal's procdump utility 

to collect crash dumps on Windows.

  Anything ?

Regadrs,

Vlad

[Dany40]

Hello Vlad, I really thank you for your interest in asking.

The best clue we have, is that this is not a problem in Firebird because we have 6 windows servers mounted in the same tenant, and we found that in most cases, when the error is reported, it appears near the same time in one of the other servers. So we moved last night all the servers to a new host, we are waiting for results.

Thank you again.

[Dany40]

Hello;

Let me ask something relative to this lock manager case. After the moment that Firebird Server find and log this lock manager event, on the client-side we are getting in the firebird log the kind of inputs I will add at the end of this message. My question is, if I can do something to stabilize the situation on the server without stopping it. Thank you a lot for any help !

SVP-NUBE-2 Fri Dec  5 12:01:24 2025
INET/inet_error: read errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:24 2025

REMOTE INTERFACE/gds__detach: Unsuccessful detach from database.
Uncommitted work may have been lost.
Error writing data to the connection.

SVP-NUBE-2 Fri Dec  5 12:01:24 2025
INET/inet_error: read errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:24 2025

REMOTE INTERFACE/gds__detach: Unsuccessful detach from database.
Uncommitted work may have been lost.
Error writing data to the connection.

SVP-NUBE-2 Fri Dec  5 12:01:24 2025
INET/inet_error: send errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:24 2025

REMOTE INTERFACE/gds__detach: Unsuccessful detach from database.
Uncommitted work may have been lost.
Error writing data to the connection.

SVP-NUBE-2 Fri Dec  5 12:01:24 2025
INET/inet_error: read errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:24 2025
INET/inet_error: read errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:24 2025
INET/inet_error: send errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:24 2025
INET/inet_error: send errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:24 2025

REMOTE INTERFACE/gds__detach: Unsuccessful detach from database.
Uncommitted work may have been lost.
Error writing data to the connection.

SVP-NUBE-2 Fri Dec  5 12:01:24 2025
INET/inet_error: send errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:25 2025
INET/inet_error: send errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:25 2025
INET/inet_error: send errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:25 2025

REMOTE INTERFACE/gds__detach: Unsuccessful detach from database.
Uncommitted work may have been lost.
Error writing data to the connection.

SVP-NUBE-2 Fri Dec  5 12:01:25 2025
INET/inet_error: send errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:25 2025
INET/inet_error: send errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:25 2025

REMOTE INTERFACE/gds__detach: Unsuccessful detach from database.
Uncommitted work may have been lost.
Error writing data to the connection.

SVP-NUBE-2 Fri Dec  5 12:01:25 2025
INET/inet_error: send errno = 10054, server host = LOCALHOST, address = ::1/3050


SVP-NUBE-2 Fri Dec  5 12:01:25 2025

REMOTE INTERFACE/gds__detach: Unsuccessful detach from database.
Uncommitted work may have been lost.
Error writing data to the connection.

SVP-NUBE-2 Fri Dec  5 12:01:25 2025
INET/inet_error: send errno = 10054, server host = LOCALHOST, address = ::1/3050

[Dimitry Sibiryakov]

Dany40 wrote 05.12.2025 19:20:
> My question is, if I can do something to stabilize the situation on the server
> without stopping it.

Why don't you use superserver mode?

--
WBR, SD.

[Dany40]

Hi, I use Firebird in the default mode. I do not change any parameter into the firebird.conf, so I use SuperServer, I guess.

BTW, is it important to chante the default LockMemSize and LockHashSlot parameters for this case:

120 databases (from 1GB to 130GB in size) on the same Firebird 5.0.3 (64 bit); 1 to 50 connections for each database (no more than 300 connections at the same time).

Let me add: 8 cores; CPU use is always less than 20%, and Memory use is always less than 40%.

Thank you very very much for any idea or help.

[Dany40]

Is it ok for the case if I run procdump in this way?:

procdump -e -ma -w fbserver.exe C:\Dumps\

Thank you!

El jueves, 4 de diciembre de 2025 a las 8:01:46 UTC-3, fbv...@gmail.com escribió:

[Vlad Khorsun]

Is it ok for the case if I run procdump in this way?:

procdump -e -ma -w fbserver.exe C:\Dumps\

  Note, correct name is firebird.exe (not fbserver, unless you are using v2.x).

Also, procdump in such scenario should be run with elevated privileges an its console should stay active.

I'd suggest to set procdump as  "Just-in-Time" debugger instead, using command "procdump -i -ma C:\Dumps"

When its not longer needed, uninstall it with "procdump -u"

Hope it helps, 

Vlad

[Dany40]

Thank you Vlad!

[Dany40]

Hello, today we received this two inputs in the firebird.log file. Is it possible both of then are related to the same issue (both at the same time)?

SVP-NUBE-1 Wed Dec 10 16:30:02 2025

Fatal lock manager error: Process disappeared in LockManager::acquire_shmem, errno: 0

SVP-NUBE-1 Wed Dec 10 16:30:03 2025
Error in journal thread
Journal file E:\JOURNAL\20042493\20042493.FDB.journal-000302157 truncate failed (error 1224)

Thank you!

[Vlad Khorsun]

Hello, today we received this two inputs in the firebird.log file. Is it possible both of then are related to the same issue (both at the same time)?

SVP-NUBE-1 Wed Dec 10 16:30:02 2025
Fatal lock manager error: Process disappeared in LockManager::acquire_shmem, errno: 0

  Do you have a memory dump ?

 

SVP-NUBE-1 Wed Dec 10 16:30:03 2025
Error in journal thread
Journal file E:\JOURNAL\20042493\20042493.FDB.journal-000302157 truncate failed (error 1224)

  Hard to say if first error caused the second one, I need memory dump to say more.

Regards,

Vlad

[Dany40]

Hello Vlad,

I started procdump in the way you suggested in 6 servers, but one our after that one of them become freezed (in some way) so we was in the need to reset it. One our after that, the same case in other server. But, in both cases Firebird didn't register an error, and of course, no dump files where created. This is the first time I see this behaviour, so I am thinking the source of this problem was the procdump app ...

These where the commands I ran for the dump:

procdump64 -i -ma E:\Dumps
procdump64 -e -ma -w firebird.exe E:\Dumps

What do you think about this?

Thank you!

[Vlad Khorsun]

Hello Vlad,

I started procdump in the way you suggested in 6 servers, but one our after that one of them become freezed (in some way) so we was in the need to reset it. One our after that, the same case in other server. But, in both cases Firebird didn't register an error, and of course, no dump files where created. This is the first time I see this behaviour, so I am thinking the source of this problem was the procdump app ...

These where the commands I ran for the dump:

procdump64 -i -ma E:\Dumps
procdump64 -e -ma -w firebird.exe E:\Dumps

What do you think about this?

  You should use only one of that commands. The first one (-i) register  procdump as "Just in time debugger".

When any process crashed, Windows attach  "Just in time debugger" to the crashed process automatically.

Then procdump will save memory dump into file at specified folder.

  The second command (-w) makes procdump watch for the specified process (firebird.exe). But it is impossible to

attach second debugger to the same process. Also, there could be a problem with security permissions when regular

process attempts to debug the service. If you already have registered  "Just in time debugger" - you need no other

means to watch for crashes.

  I recommend to set  procdump as  "Just in time debugger" (using first command, only once!) and let Windows call

it when process crashes.

Hope it is more clear now,

Vlad

[Dany40]

Yes, thank you.

[Dany40]

Hello Vlad,

I received a new fatal error today, please let me know if this dump is usefull:

https://drive.google.com/file/d/1bb7axFonGK6cVrKeS0eSbrtXCDTCjLcq/view?usp=sharing

Regards!

Dany

El jueves, 11 de diciembre de 2025 a las 16:23:45 UTC-3, fbv...@gmail.com escribió:

[Vlad Khorsun]

Hello Vlad,

I received a new fatal error today, please let me know if this dump is usefull:

  Sorry, but this is memory dump of working (actually - idle) FIrebird process. It was not produced by crash.

Regards,

Vlad

[Vlad Khorsun]

  I've read it again

 

These where the commands I ran for the dump:

procdump64 -i -ma E:\Dumps

 

and should note:

- there is no procdump64, just procdump - maybe you use some old copy ?

Actual version is here https://learn.microsoft.com/en-us/sysinternals/downloads/procdump

- correct command is "procdump -ma -i E:\Dump" (look at order of switches), in your case  (-i -ma) 

the dumps would be put into folder where procdump is located

- just in case: this commad required admin privileges and should be run using elevated console.

Hope this helps,

Vlad

[Dany40]

Very sorry to say that you are wrong. This is what you will find in the file you sent by that link:

[Vlad Khorsun]

Very sorry to say that you are wrong. This is what you will find in the file you sent by that link:

  Conrgats you catch me not looking into archive contents. Hope, it helped to setup procdump correctly and 

finally get crash dump. I wonder why it is so hard...

Regards,

Vlad