FBCLIENT.DLL forces Delphi to ignore EZeroDivide exceptions [CORE4043] #4373
Submitted by: Pablo Romero (pabloromero)
I have a Delphi database application that is currently running on FB 2.5 server. Application was working OK for several years on previous FB versions. I switched
This year I noticed a couple of cases when there was "INF" value written in double precision field in database. I also noticed, that Delphi Try / Except / End
Imagine a case like this:
Exception is not raised on C calculation and C is calculated as INF "infinity" number.
Well: I can change that and check if B is zero and do workaround, but there is Delphi VCL that depends on exception being raised!
By default, Delphi sets FPU Control Word to raise exceptions.
You can read more about that here:
So, when I was looking for DLL that my application loads that disables FPU exceptions, I realised that it is Firebird Client library or its MSVC RTL.
Every time you connect to a database, all exceptions are disabled. You execute a query, and all exceptions are disabled.
What I found out is that my Delphi application catches exceptions, working ok, if I use FB client from version 1.5 up to version 2.1.4.
With Fbclient.dll 2.5 there are problems.
¿Is FB Client that is builded with disabled FPU exceptions catching or is it MSVC RTL?. I dont know if MSVC RTL changed from FB 2.1.4 to FB 2.5 or it is the same.
If I set FPU control manualy in my application it works only for a couple of lines, until another "Select..." of code, and it is back disabled again, so this is not a solution.
Currently I am using 2.1.4 client to be on the safe side.
The text was updated successfully, but these errors were encountered:
Commented by: @AlexPeshkoff
Suppose first of all we should confirm an issue - there is a change in fb 2.5 that may cause such a behavior. On the other hand in trivial case (single thread) state of FPU was designed to be restored when leaving client. Can someone re-check it on windows?
On the other hand looking once again at the code looks like in MT case we have definite bug. Moreover - for embedded case if one thread works inside fb engine but another in user's code they have different FPU control word requirements, and probably changin it in our code is bad idea in generic.
Commented by: Simon (daytripper)
Most of this ticket is my report on Firebird-Support:
FB 2.5 Client library is a no-go for Delphi users that relay on catching EZeroDivide errors.
Commented by: michalk1 (michalk1)
I can also confirm the issue. I tested basic single thread operations and found that most fbclient functions change the masks. FPU returns with all masks except DM set (bits 0,2,3,4 and 5). There are few "local" functions that keep the settings untouched (isc_decode_date, isc_dsql_describe, isc_vax_integer, isc_interprete etc.), but all other are affected (isc_database_info, isc_attach_database, isc_dsql_execute2, isc_dsql_fetch, isc_dsql_free_statement, isc_commit_transaction, isc_service_start etc.). The problem is specific to FB 2.5 client library, FB 2.1 is ok.
Commented by: Jared Davison (jared)
We have found a problem that the FPU control word mask is not preserved between calls to FBCLIENT.dll functions such isc_attach_database().
This results in unexpected behavior in the calling application.
We observed this bug under Win32 fbclient.dll 184.108.40.206074, 220.127.116.1139.
We have observed that this has been *fixed* in release Firebird 2.5.3 release (18.104.22.168778). We cannot find a description of the fix in the release notes possibly because this is an incomplete solution and workaround.
We have found the following comments inside src\common\classes\FpeControl.h which suggests the resolution of this is issue incomplete.
This subtle bug can have serious consequences in an application that uses floating point. We suggest a unit test around this issue to ensure this is not broken in future.
Mutithreaded support is mandatory to resolve this.