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
connections to FB3 in "standaloneClassic" mode (firebird -s) hang up [CORE4586] #4902
Comments
Commented by: @mkubecek Packet captures and strace outputs, both for the "good" (multithreaded server) and "bad" (standaloneClassic, firebird -s) case. |
Modified by: @mkubecekAttachment: fb3-s.tar.gz [ 12601 ] |
Modified by: @AlexPeshkoffassignee: Alexander Peshkov [ alexpeshkoff ] |
Modified by: @AlexPeshkoffFix Version: 3.0 Beta 1 [ 10332 ] |
Commented by: @mkubecek Tentative fix attached. The problem was that SRVR_multi_thread() read the 428 bytes from client into port->port_queue but then inet_getbytes() found SRVR_debug in port->port_server_flags and tried to read from the connection rather than use the queued data. The flag is set in INET_connect() when child is forked (or we don't fork a child and just exchange the socket in the same process in debug mode) #ifdef WIN_NT This is done even if SRVR_debug is not set in flags. However, as today all server code path go through SRVR_multi_thread(), inet_getbytes should always use REMOTE_getbytes() for server ports. And as this seems to be the only place where rem_port.port_server_flags is checked and it's not set for classic or superserver, I believe there is no need to set the flag in rem_port.port_server_flags at all. |
Modified by: @mkubecekAttachment: core-4586.patch [ 12603 ] |
Commented by: @dyemanov > today all server code path go through SRVR_multi_thread() |
Commented by: @mkubecek Yes, that's true. But as far as I can see, WNET and XNET servers have their own xdr_ops so that they are not using inet_getbytes() and the patch wouldn't affect them. Right? |
Commented by: @dyemanov It looks right. |
Commented by: @mkubecek Committed the fix (r60144). |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0 Beta 1 [ 10332 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: @mkubecek
Attachments:
fb3-s.tar.gz
core-4586.patch
When the "standaloneClassic" server is started with
"/usr/sbin/firebird -s" and connection to it is created e.g. with
echo 'show tables;' | isql -ch UTF8 '172.17.2.1:test'
The query hangs up. Without "-s" option everything works fine, as well
as in the usual "classic" mode (started via xinetd).
From the network communication and strace output (I'll attach them in a
moment), it seems that in both cases, the connection is established and
first data packet from client (428 bytes, looks like authentication) is
read. While in the multithreaded case, server reads configuration
(firebird.conf, databases.conf) and responds to the packet, forked child
in standalone case just calls poll() on connected socket again so that
from that moment on, both client and server wait for data from the other
side.
Commits: e7308c1 FirebirdSQL/fbt-repository@13807e5
The text was updated successfully, but these errors were encountered: