firebird icon indicating copy to clipboard operation
firebird copied to clipboard

Wire compression causes "Error reading data from the connection" under specific conditions

Open michalk1111 opened this issue 3 months ago • 4 comments

This issue is somewhat similar to long time fixed https://github.com/FirebirdSQL/firebird/issues/6700 (caused by wire compression; only the affected connection is dropped, the server doesn’t crash), but it only occurs under the following specific conditions (all must be met):

  • A new client (FB 5.0 or FB 4.0 line) connects to FB 3.0 server. (I can’t reproduce it when connecting a 3.0 client to a 3.0 server or a 5.0 client to a 5.0 server.).

  • Several active connections to different databases. (I can’t reproduce it with only one active client application.)

  • It probably occurs only when some databases are being dropped or created. (I can’t reproduce it during normal use of already existing databases.)

  • Wire compression must be activated via the database DPB parameter (config='WireCompression=true' in Database.Params). I cannot reproduce it when wire compression was already enabled in the client-side firebird.conf file. (So, if there is a client-side firebird.conf, its WireCompression setting must be either false or commented out in order to reproduce the error. If it is set to true, the DPB parameter doesn’t change anything and the bug does not appear.)

Since it is difficult or impossible to achieve all these conditions in ISQL, I have prepared a specific Windows test case application (Delphi sources attached). All it does is repeatedly create and drop specified databases. Wire compression is actually activated just for a moment before the database is dropped, but that is sufficient to trigger the bug. Tested with 5.0.3.1683 32-bit fbclient.dll and 3.0.13.33818 64-bit server,

To reproduce the error:

  1. Unzip the attached files TestApp.zip.
  2. Run several instances (2 as a minimum, 3-4 recommended) of TestApp.exe.
  3. Fill in distinct database names (e.g., Test1.fdb in the first application instance, Test2.fdb in the second, etc.). Make sure the folder selected for databases (default: C:\Tmp) exists. Connections must use TCP/IP.
  4. Click Run in all applications so that they execute in parallel.
  5. The errors "Error reading data from the connection" should appear shortly.

michalk1111 avatar Sep 23 '25 06:09 michalk1111

Dependency of server crash from a way how compression is turned on at client side appears to be something extra-ordinary. Can you also provide server's stack traces when it dies?

AlexPeshkoff avatar Sep 23 '25 07:09 AlexPeshkoff

As I mentioned in the issue report, the server doesn't crash. The bug seems to affect only client connections. When it happens, other connections go on working (at least for some time, until they are also affected).

michalk1111 avatar Sep 23 '25 07:09 michalk1111

Sorry, it seemed to me from the text that it's about fixed #6700. Will try to reproduce.

AlexPeshkoff avatar Sep 23 '25 08:09 AlexPeshkoff

Any progress on the issue? I’ve found some more clues in the meantime:

It seems that the "error reading" exception is (sporadically) raised only when a connection has WireCompression turned off, while at the same time, there are other active connections with WireCompression turned on.

In the test case application, the failing command is the Db.CreateDatabase() call, but I have already found that even opening an existing database using Db.Open() may fail as well.

In the case of Db.Open(), the problem can be mitigated by always setting WireCompression to true via DPB. However, such a solution is probably not applicable for Db.CreateDatabase(), since (at least in IBX components) it is implemented via an isc_dsql_execute_immediate call with a 'CREATE DATABASE' command and parameters in text form — which likely means there is no way to set the DPB here.

The new findings also explain why I wasn't able to reproduce the error using a client-side firebird.conf, since it was shared by all tested client processes — meaning all of them had WireCompression turned on.

The clue concerning DPB versus firebird.conf was misleading. The key factor is having multiple attachments — at least one with WireCompression turned off, and the rest connected to another database with WireCompression turned on.

I also created a new test case, this time based only on isql (remember to connect it to FB 3.0 line server):

IsqlTestCase.zip

  • Unzip the attached files into the C:\Tmp directory.
  • Open at least three command-line consoles. In the first one, run RunFalse.bat; in the others, run RunTrue.bat.
  • You should soon see "Error reading ..." messages in the console running without wire compression (RunFalse.bat).

michalk1111 avatar Oct 15 '25 08:10 michalk1111