Hi All!

I have currently been looking into an issue where one of our clients seem to be experiencing a deadlock. However I am not a Firebird expert so I think I might need some help, hopefully someone could point me in the right direction. In short:

I have narrowed it down to being due to one of our threads on the server acquiring a lock then entering gds32.dll (fbclient.dll) never to return.

An memory dump taken early in the investigation seemed to indicate a hang in winsock2 select method.

During my investigation I have made some memory dumps + modified the source of fbclient for improved trace logging. I have also added configuration regarding connection and dummy message timout, since it seems that these values are sometimes used as the timeout value for the winsock2 select call. In order to make sure that the thread does not hang in a blocking winsock call I also changed to code (in fbclient.dll) so that timeout is always set. The conclusion is that the select call never returns a FD_SET for the thread causing the hang. MON$STATEMENTS show that I have a stalled statement timestamped at around the time of the hang. The SQL in the statement corresponds to the SQL expected to be executed by the thread that is causing the hang ( a SELECT statement).

We are using:

Firebird 2.5.4 (in our clients system), Firebird 2.5.6 in our test system

ibproviderV2

MDAC 2.7

The system is a client server application, 4 clients connected to a server application which utilizes Firebird. The server application and Firebird coexists on the same physical machine.

Question is, could this occur because we are using WAIT transactions (which is the deafult if I have understood correctly), or bad management of transactions(I have used fb_lock_print for one reproduced hang without finding any lock blocks)? Or is it an firebird issue?

More information from memory dumps/trace etc. can be provided upon request

Thanks in advance!

/John Karlsson