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

connections to FB3 in "standaloneClassic" mode (firebird -s) hang up [CORE4586] #4902

Closed
firebird-automations opened this issue Oct 23, 2014 · 14 comments

Comments

@firebird-automations
Copy link
Collaborator

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

@firebird-automations
Copy link
Collaborator Author

Commented by: @mkubecek

Packet captures and strace outputs, both for the "good" (multithreaded server) and "bad" (standaloneClassic, firebird -s) case.

@firebird-automations
Copy link
Collaborator Author

Modified by: @mkubecek

Attachment: fb3-s.tar.gz [ 12601 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Fix Version: 3.0 Beta 1 [ 10332 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Version: 3.0 Beta 1 [ 10332 ]

Fix Version: 3.0 Beta 1 [ 10332 ] =>

@firebird-automations
Copy link
Collaborator Author

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
if (flag & SRVR_debug)
#⁠else
if ((flag & SRVR_debug) || !fork())
#⁠endif
{
SOCLOSE(port->port_handle);
port->port_handle = s;
port->port_server_flags |= SRVR_server | SRVR_debug;
port->port_flags |= PORT_server;
return port;
}

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @mkubecek

Attachment: core-4586.patch [ 12603 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

> today all server code path go through SRVR_multi_thread()
Not in Windows. WNET and XNET protocols still don't use SRVR_multi_thread().

@firebird-automations
Copy link
Collaborator Author

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?

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

It looks right.

@firebird-automations
Copy link
Collaborator Author

Commented by: @mkubecek

Committed the fix (r60144).

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0 Beta 1 [ 10332 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: Cannot be tested

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

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