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

When 32bit and 64bit FB 3 servers run on one Windows machine concurrently, Firebird services freeze several minutes after first disconnect. [CORE5515] #5784

Closed
firebird-automations opened this issue Apr 5, 2017 · 17 comments · Fixed by #314

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: michalk1 (michalk1)

Attachments:
CORE-5515.7z

Steps to reproduce:
1) Install FB3.0.2 64bit with default settings (port 3050, service name DefaultInstance)
2) Use FB3.0.2 32bit zip package to install another FB instance at the same machine, change its RemoteServicePort in firebird.conf (e.g. to 3051), setup its security database and use instsvc to configure and start the service (named say FB30)
instsvc i -n FB30
instsvc start -n FB30
3) Run isql from DefaultInstance server and make TCP connect to its employee database
isql -user sysdba -password masterkey localhost/3050:employee
4) Run isql from FB30 server instance and connect to its employee database as well
isql -user sysdba -password masterkey localhost/3051:employee
5) Close both connections and isql consoles (ctrl+z)
6) Wait at least two minutes
7) Now, when trying to connect again to any database, isql console freezes. Both FB services are stuck as well and must be killed from task manager.

Clues:
The problem is not isql or database specific, you can use i.e. FlameRobin, and connect to any database to demonstrate the problem.
What is weird is the time limit required in step 6, because when the new connection is established fast enough (in less than about those two minutes), everything continues to work.
Two FB 3 64bit or two 32bit servers work together ok, it is only combination of 32bit and 64bit servers that cause hangs.

Commits: 90270cd ffaf62b

@firebird-automations
Copy link
Collaborator Author

Modified by: michalk1 (michalk1)

description: Steps to reproduce:
1) Install FB3.0.2 64bit with default settings (port 3050, service name DefaultInstance)
2) Use FB3.0.2 32bit zip package to install another FB instance at the same machine, change its RemoteServicePort in firebird.conf (e.g. to 3051), setup its security database and use svcmgr to configure and start the service (named say FB30)
instsvc i -n FB30
instsvc start -n FB30
3) Run isql from DefaultInstance server and make TCP connect to its employee database
isql -user sysdba -password masterkey localhost/3050:employee
4) Run isql from FB30 server instance and connect to its employee database as well
isql -user sysdba -password masterkey localhost/3051:employee
5) Close both connections and isql consoles (ctrl+z)
6) Wait at least two minutes
7) Now, when trying to connect again to any database, isql console freezes. Both FB services are stuck as well and must be killed from task manager.

Clues:
The problem is not isql or database specific, you can use i.e. FlameRobin, and connect to any database to demonstrate the problem.
What is weird is the time limit required in step 6, because when the new connection is established fast enough (in less than about those two minutes), everything continues to work.
Two FB 3 64bit or two 32bit servers work together ok, it is only combination of 32bit and 64bit servers that cause hangs.

=>

Steps to reproduce:
1) Install FB3.0.2 64bit with default settings (port 3050, service name DefaultInstance)
2) Use FB3.0.2 32bit zip package to install another FB instance at the same machine, change its RemoteServicePort in firebird.conf (e.g. to 3051), setup its security database and use instsvc to configure and start the service (named say FB30)
instsvc i -n FB30
instsvc start -n FB30
3) Run isql from DefaultInstance server and make TCP connect to its employee database
isql -user sysdba -password masterkey localhost/3050:employee
4) Run isql from FB30 server instance and connect to its employee database as well
isql -user sysdba -password masterkey localhost/3051:employee
5) Close both connections and isql consoles (ctrl+z)
6) Wait at least two minutes
7) Now, when trying to connect again to any database, isql console freezes. Both FB services are stuck as well and must be killed from task manager.

Clues:
The problem is not isql or database specific, you can use i.e. FlameRobin, and connect to any database to demonstrate the problem.
What is weird is the time limit required in step 6, because when the new connection is established fast enough (in less than about those two minutes), everything continues to work.
Two FB 3 64bit or two 32bit servers work together ok, it is only combination of 32bit and 64bit servers that cause hangs.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Stefan Heymann posted to the Devel mailing list:

Try to use instreg to un-register the 64-bit installation from the Registry. If you have more that one database (Sic, should be engine) on one server it's best to have none of them being registered in the Registry.

@firebird-automations
Copy link
Collaborator Author

Commented by: michalk1 (michalk1)

Stefan, thanks for the tip. I tried it, but deleting the registry key doesn't make any difference. To be sure, I made another test on a clean Windows 7 system without any previous FB installations, and this time I installed both 32+64 bit FB 3.0.2 manually from zip packages. But results are still the same, both services tend to hang. In log files, there are no messages except obvious complaints about XNET server initialization (because I didn't change IpcName in firebird.conf). May be I do something wrong in the manual installation process, but then, why would the 32+32 and 64+64 combinations work ok ? I will try to run more tests next week.

@firebird-automations
Copy link
Collaborator Author

Commented by: michalk1 (michalk1)

I tested it once more, but with no luck. I installed 2x 64 bit FB and 2x 32 bit FB from zip packages on a single Windows 10 host and made isql connections to different combinations of the services. Things work as long as I connect to servers with the same bitness, but once I connect to the other bitness, only the first try succeeds. About two minutes after I close both the isql sessions, all the services hung and must be killed (or machine restarted). I also tested 32+64 combination of FB 2.5.7, but that seems to work ok.

So, is there anybody who runs the Windows 32+64 FB 3 combination successfully ?

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Is it possible that you have multiple FBClient.dll's installed in SYSTEM\SYSTEM32 folders?

What is the bitness of your application(s)?

@firebird-automations
Copy link
Collaborator Author

Commented by: michalk1 (michalk1)

As for the recent test, there are no FBClient dlls in Windows system folders, only in individual FB server installation directories (32/64 depending on server bitness). As an aplication I now used isql consoles, 32 bit or 64 bit. But the problem doesn't seem to be dependent on bitness of the client application.

@firebird-automations
Copy link
Collaborator Author

Commented by: michalk1 (michalk1)

I made new tests on Windows 10 with current FB versions - FB 4.0 snapshot build (4.0.0.955) and FB 3.0.3 (3.0.3.32900). Unfortunatelly, the problem presists, here is what I found:

FB 3.0 32 bit + FB 3.0 64 bit ---> freeze
FB 4.0 32 bit + FB 4.0 64 bit ---> freeze
FB 4.0 32 bit + FB 3.0 32 bit ---> ok
FB 4.0 32 bit + FB 3.0 64 bit ---> ok
FB 4.0 64 bit + FB 3.0 32 bit ---> ok
FB 4.0 64 bit + FB 3.0 64 bit ---> ok

It seems that 32 and 64 bit services of the same FB version must have something in common (shared locks or another resource that gets inappropriately unalocated ?) which causes them to lock each other.

Btw, to run FB 4.0 zip kits, it was also necessary to pre-install msvc 2010 redistributable, otherwise every database connect stopped with "Could not find acceptable ICU library" error.

@firebird-automations
Copy link
Collaborator Author

Modified by: michalk1 (michalk1)

Version: 3.0.3 [ 10810 ]

Version: 4.0 Alpha 1 [ 10731 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Reproduced and investigated

@firebird-automations
Copy link
Collaborator Author

Commented by: Basil A. Sidorov (basid)

Run 32- and 64-bit Firebird 3.0.4-33054 as application.
Run some script for create and load two database for tpc-c (zero warehouse).
Wait more then two minuties and try connect via isql:
Authentication error
connection shutdown
in firebird.log for both instances.

Both instance hang on shutdown.
Make dump (procdump -mp), add firebird.conf/.log/e.t.c, compress and attach to ticket.

@firebird-automations
Copy link
Collaborator Author

Modified by: Basil A. Sidorov (basid)

Attachment: CORE5515.7z [ 13313 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

So far it is impossible to run both 32 and 64-bit Firebird processes of the same version at the same time.
Some common shared memory data have different internal structure.
Probably could be fixed in v4.

@marcosfba
Copy link

Tenho uma aplicação utilizando as seguintes versões do firebird de modo embarcado Firebird 2.5.9 e Firebird 3.0.7 de modo concomitante e varias conexões simultâneas funcionando perfeitamente. Ao adicionar a versão do Firebird 4.0.0 na aplicação sistema operacional entra em conflito conforme imagem abaixo:
image
Gostaria de saber como resolver.

@mrotteveel
Copy link
Member

@marcosfba Please post in English

@marcosfba
Copy link

I have an application using the following versions of firebird in embedded mode Firebird 2.5.9 and Firebird 3.0.7 concurrently and several simultaneous variants working perfectly. When adding the version of Firebird 4.0.0 in the operating system application, it conflicts as shown below: I would like to know how to solve it?
https://user-images.githubusercontent.com/12546259/130676224-d7b26801-0f66-4a91-9145-d7ce45eea2a8.png

@marcosfba
Copy link

marcosfba commented Aug 24, 2021 via email

@mrotteveel
Copy link
Member

@marcosfba I recommend you post a question to the firebird-support Google Group. If you're sure this is a bug in Firebird, then create a new issue instead of trying to repurpose an existing issue. Make sure to include all the necessary information to reproduce the problem.

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