VC++ IBPP / Firebird 客户端在 x86 和 x64 上的异常处理不同
VC++ Exception Handling differ on x86 and x64 for IBPP / Firebird client
我在 Visual Studio 2015 / VC++ 与 IBPP 进行交流。 IBPP 是 firebird / interbase API 的 c++ 包装器。
IBPP, a C++ Client Interface to Firebird Server
这个包的一部分是一个小测试套件，你可以在这里下载：
ibpp-2-5-3-1-src.zip
要从测试套件开始，您会在
下找到一个简单的批处理文件来编译它
x:...\ibpp-2-5-3-1-src\tests\vs2005\simplest-build.bat
使用 vc++ 2015 的原生 x86 和 x64 工具链可以很好地编译。
编译之前你需要编辑
的第84到86行
x:...\ibpp-2-5-3-1-src\tests\tests.cpp
const char* DbName = "x:/ibpptest/test.fdb"; // FDB extension (GDB is hacked by Windows Me/XP "System Restore")
const char* BkName = "x:/ibpptest/test.fbk";
const std::string ServerName = ""; //"localhost"; // Change to "" for local protocol / embedded
请注意创建目录x:\ibpptest\。
此外，您需要下载 fblient 文件，这些文件本身不可用，但作为整个服务器存档的一部分。获取这两个文件：
32-bit Embedded
和
64-bit Embedded
.
为了简化，在 x:\...\ibpp-2-5-3-1-src\tests\vs2005\ 之外创建两个目录：
x:\...\ibpp-2-5-3-1-src\tests\vs2015x86\
x:\...\ibpp-2-5-3-1-src\tests\vs2015x84\
并将x:\...\ibpp-2-5-3-1-src\tests\vs2005\simplest-build.bat复制到其中。现在将 fbclient 文件（32 位到 x86，64 位到 x64）复制到这些目录中：
intl/*
udf/*
fbembed.dll
firebird.msg
ib_util.dll
icudt30.dll
icuin30.dll
icuuc30.dll
msvcp80.dll
msvcr80.dll
现在可以编译启动了tests.exe。 x86 二进制文件在测试 6 中产生了一些错误，这没关系，因为您使用的是 fblient 文件的嵌入式版本。 x64 二进制文件将在 Windows 程序失败屏幕中结束。当测试套件激活异常时，这发生在 Test3 中：
try
{
#if defined(IBPP_WINDOWS) && defined(_DEBUG)
OutputDebugString(_("An exception will now get logged in the debugger: this is expected.\n"));
#endif
st1->ExecuteImmediate( "CREATE SYNTAX ERROR(X, Y) AS "
"SELECT ERRONEOUS FROM MUSTFAIL M" );
}
catch(IBPP::SQLException& e)
{
//~ std::cout<< e.what();
if (e.EngineCode() != 335544569)
{
_Success = false;
printf(_("The error code returned by the engine during a\n"
"voluntary statement syntax error is unexpected.\n"));
}
}
在 x86 二进制文件中，此异常按预期被捕获，但在 x64 二进制文件中则不会。有人知道如何在 x64 二进制文件中实现类似的异常处理吗？
在此先感谢您的帮助！
警告：我使用 Visual Studio 2017 环境来 运行 最简单的-build.bat 文件。
从我在下面提供的证据来看，Firebird 服务的 32 位和 64 位版本之间存在分叉或其他编译差异，导致了此问题。
解决：EngineCode()成员函数在64位版本中不存在。您必须使用异常的 what() 成员函数，如 Test3() catch 块内注释掉的行所示。如果您希望使用 EngineCode 信息，您将不得不从 what() 字符串中解析它，因为它包含最初作为 32 的 IBPP::SQLExceptionImpl class 中的单独数据成员提供的所有信息位.
try
{
#if defined(IBPP_WINDOWS) && defined(_DEBUG)
OutputDebugString(_("An exception will now get logged in the debugger: this is expected.\n"));
#endif
st1->ExecuteImmediate( "CREATE SYNTAX ERROR(X, Y) AS "
"SELECT ERRONEOUS FROM MUSTFAIL M" );
}
catch(IBPP::SQLException& e)
{
//~ std::cout<< e.what();
printf(e.what());
//if (e.EngineCode() != 335544569)
//{
// _Success = false;
// printf(_("The error code returned by the engine during a\n"
// "voluntary statement syntax error is unexpected.\n"));
//}
}
what() 调用的结果。
*** IBPP::SQLException ***
Context: Statement::ExecuteImmediate( CREATE SYNTAX ERROR(X, Y) AS SELECT ERRONEOUS FROM MUSTFAIL M )
Message: isc_dsql_execute_immediate failed
SQL Message : -104
can't format message 13:896 -- message file C:\WINDOWS\SYSTEM32\firebird.msg not found
Engine Code : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, column 8
SYNTAX
谜题：statement.cpp显示了IBPP::SQLExceptionImpl和其他...ExceptionImpl的用法，所以我不得不相信这个源代码是32位分支。如果这应该是 32 位和 64 位的公共分支，那么我看不出它是如何工作的。
有两个头文件定义了异常classes。我相信 _ibbp.h 用于编译 32 位客户端，而 ibbp.h 用于 64 位客户端。我通过更改 Test3() 中的 catch 子句以查看可能发生的异常情况得出了这些结论。 ...ExceptionImpl classes 只能使用 32 位客户端 dll 进行编译，而不能使用 64 位 dll 进行编译。
来自 _ibpp.h（32 位 fbclient dll 识别这些 classes。64 位 fbclient dll 不识别。）
///////////////////////////////////////////////////////////////////////////////
//
// Implementation of the "hidden" classes associated with their public
// counterparts. Their private data and methods can freely change without
// breaking the compatibility of the DLL. If they receive new public methods,
// and those methods are reflected in the public class, then the compatibility
// is broken.
//
///////////////////////////////////////////////////////////////////////////////
//
// Hidden implementation of Exception classes.
//
/*
std::exception
|
IBPP::Exception
/ \
/ \
IBPP::LogicException ExceptionBase IBPP::SQLException
| \ / | \ /
| LogicExceptionImpl | SQLExceptionImpl
| |
IBPP::WrongType |
\ |
IBPP::WrongTypeImpl
*/
来自 ibpp.h（两个 fbclient dll 集都识别这些 classes）
/* IBPP never return any error codes. It throws exceptions.
* On database engine reported errors, an IBPP::SQLException is thrown.
* In all other cases, IBPP throws IBPP::LogicException.
* Also note that the runtime and the language might also throw exceptions
* while executing some IBPP methods. A failing new operator will throw
* std::bad_alloc, IBPP does nothing to alter the standard behaviour.
*
* std::exception
* |
* IBPP::Exception
* / \
* IBPP::LogicException IBPP::SQLException
* |
* IBPP::WrongType
*/
在所有 tests.cpp 中，IBPP::SQLException 的唯一问题是在 Test3() 中。每隔一个 catch 使用 IBPP::Exception.
所以这个问题只会在编译 64 位时出现在 Test3() 中，但我认为只要在 64 位实现中使用 IBPP::SQLException 它就会出现。
经过大量研究，我找到了原因。我错误地认为 x86 和 x64 中的异常处理不同。 IBPP 库包含一个错误（自 10 年以来！），它只在 x64/windows szenario 中发生，当 firebird 库向调用者报告一个（复杂的）错误条件时。
那么会发生什么：
测试程序调用 IBPP 库。 IBPP 库调用 firebird API/ 库。 firebird 库在长数组 [20] 中报告其调用结果，他们称之为 "ISC_STATUS vector"。 IBPP 库检查此结果，如果出现错误，它会抛出异常。测试程序捕获此类异常并报告给用户。
到目前为止，还不错。但问题是，IBPP 将 ISC_STATUS 定义为 longs 的数组 [20]，就像火鸟一样，它在 v2.0 之前也是如此——它只支持 x86 windows。从 v2.1 开始，firebird 支持 x64 windows 并将 ISC_STATUS 定义为 intptr_t 的数组，这会导致 "long long" on windows x64 LLP64 编译器并继续LP64 linux 编译器 - 都是 64 位宽。在 ILP32 windows 和 linux x86 编译器上 intptr_t 是 32 位宽。
IBPP 并没有缩小与 firebird 的差距，而是一直保持其对 ISC_STATUS 的定义——这导致 LLP64 windows x64 系统上的数据类型为 32 位（但在 [=53 上为 64 位） =]，因为 linux 上的 gcc 使用 LP64 系统，所以错误只发生在 windows)。
所以 firebird x64 API 向 64 位整数的 "by reference parameter" 数组 [20] 报告最多 20 个状态整数。 FBPP 库传递一个 32 位整数数组 [20]。当 firebird API 将值存储在数组的后半部分时，它会覆盖调用者的内存。在这种情况下，ISC_STATUS 向量之后的下一个字节由 C++ 字符串对象占用。状态数组和字符串都是 IBS（interbase status）class 的一部分。许多 IBPP 函数经常实例化此 class 的本地对象以管理 firebird API 结果和错误描述字符串。当函数退出时，框架会清理此类本地对象并尝试释放字符串，但它在内存中的元数据已被 firebird 覆盖API。
所以本地IBS对象的清理导致了一个未知的软件异常，它过度驱动了IBPP框架抛出的异常。而且这个异常不是被测试程序捕获的，而是被 windows / dr.华生.
我将 ISC_STATUS 的定义从 "long" 修改为 "intptr_t"，并且一切正常。
谢谢大家的指点。
我在 Visual Studio 2015 / VC++ 与 IBPP 进行交流。 IBPP 是 firebird / interbase API 的 c++ 包装器。 IBPP, a C++ Client Interface to Firebird Server
这个包的一部分是一个小测试套件，你可以在这里下载： ibpp-2-5-3-1-src.zip
要从测试套件开始，您会在
下找到一个简单的批处理文件来编译它x:...\ibpp-2-5-3-1-src\tests\vs2005\simplest-build.bat
使用 vc++ 2015 的原生 x86 和 x64 工具链可以很好地编译。
编译之前你需要编辑
的第84到86行x:...\ibpp-2-5-3-1-src\tests\tests.cpp
const char* DbName = "x:/ibpptest/test.fdb"; // FDB extension (GDB is hacked by Windows Me/XP "System Restore")
const char* BkName = "x:/ibpptest/test.fbk";
const std::string ServerName = ""; //"localhost"; // Change to "" for local protocol / embedded
请注意创建目录x:\ibpptest\。
此外，您需要下载 fblient 文件，这些文件本身不可用，但作为整个服务器存档的一部分。获取这两个文件： 32-bit Embedded 和 64-bit Embedded .
为了简化，在 x:\...\ibpp-2-5-3-1-src\tests\vs2005\ 之外创建两个目录：
x:\...\ibpp-2-5-3-1-src\tests\vs2015x86\
x:\...\ibpp-2-5-3-1-src\tests\vs2015x84\
并将x:\...\ibpp-2-5-3-1-src\tests\vs2005\simplest-build.bat复制到其中。现在将 fbclient 文件（32 位到 x86，64 位到 x64）复制到这些目录中：
intl/*
udf/*
fbembed.dll
firebird.msg
ib_util.dll
icudt30.dll
icuin30.dll
icuuc30.dll
msvcp80.dll
msvcr80.dll
现在可以编译启动了tests.exe。 x86 二进制文件在测试 6 中产生了一些错误，这没关系，因为您使用的是 fblient 文件的嵌入式版本。 x64 二进制文件将在 Windows 程序失败屏幕中结束。当测试套件激活异常时，这发生在 Test3 中：
try
{
#if defined(IBPP_WINDOWS) && defined(_DEBUG)
OutputDebugString(_("An exception will now get logged in the debugger: this is expected.\n"));
#endif
st1->ExecuteImmediate( "CREATE SYNTAX ERROR(X, Y) AS "
"SELECT ERRONEOUS FROM MUSTFAIL M" );
}
catch(IBPP::SQLException& e)
{
//~ std::cout<< e.what();
if (e.EngineCode() != 335544569)
{
_Success = false;
printf(_("The error code returned by the engine during a\n"
"voluntary statement syntax error is unexpected.\n"));
}
}
在 x86 二进制文件中，此异常按预期被捕获，但在 x64 二进制文件中则不会。有人知道如何在 x64 二进制文件中实现类似的异常处理吗？
在此先感谢您的帮助！
警告：我使用 Visual Studio 2017 环境来 运行 最简单的-build.bat 文件。
从我在下面提供的证据来看，Firebird 服务的 32 位和 64 位版本之间存在分叉或其他编译差异，导致了此问题。
解决：EngineCode()成员函数在64位版本中不存在。您必须使用异常的 what() 成员函数，如 Test3() catch 块内注释掉的行所示。如果您希望使用 EngineCode 信息，您将不得不从 what() 字符串中解析它，因为它包含最初作为 32 的 IBPP::SQLExceptionImpl class 中的单独数据成员提供的所有信息位.
try
{
#if defined(IBPP_WINDOWS) && defined(_DEBUG)
OutputDebugString(_("An exception will now get logged in the debugger: this is expected.\n"));
#endif
st1->ExecuteImmediate( "CREATE SYNTAX ERROR(X, Y) AS "
"SELECT ERRONEOUS FROM MUSTFAIL M" );
}
catch(IBPP::SQLException& e)
{
//~ std::cout<< e.what();
printf(e.what());
//if (e.EngineCode() != 335544569)
//{
// _Success = false;
// printf(_("The error code returned by the engine during a\n"
// "voluntary statement syntax error is unexpected.\n"));
//}
}
what() 调用的结果。
*** IBPP::SQLException ***
Context: Statement::ExecuteImmediate( CREATE SYNTAX ERROR(X, Y) AS SELECT ERRONEOUS FROM MUSTFAIL M )
Message: isc_dsql_execute_immediate failed
SQL Message : -104
can't format message 13:896 -- message file C:\WINDOWS\SYSTEM32\firebird.msg not found
Engine Code : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, column 8
SYNTAX
谜题：statement.cpp显示了IBPP::SQLExceptionImpl和其他...ExceptionImpl的用法，所以我不得不相信这个源代码是32位分支。如果这应该是 32 位和 64 位的公共分支，那么我看不出它是如何工作的。
有两个头文件定义了异常classes。我相信 _ibbp.h 用于编译 32 位客户端，而 ibbp.h 用于 64 位客户端。我通过更改 Test3() 中的 catch 子句以查看可能发生的异常情况得出了这些结论。 ...ExceptionImpl classes 只能使用 32 位客户端 dll 进行编译，而不能使用 64 位 dll 进行编译。
来自 _ibpp.h（32 位 fbclient dll 识别这些 classes。64 位 fbclient dll 不识别。）
///////////////////////////////////////////////////////////////////////////////
//
// Implementation of the "hidden" classes associated with their public
// counterparts. Their private data and methods can freely change without
// breaking the compatibility of the DLL. If they receive new public methods,
// and those methods are reflected in the public class, then the compatibility
// is broken.
//
///////////////////////////////////////////////////////////////////////////////
//
// Hidden implementation of Exception classes.
//
/*
std::exception
|
IBPP::Exception
/ \
/ \
IBPP::LogicException ExceptionBase IBPP::SQLException
| \ / | \ /
| LogicExceptionImpl | SQLExceptionImpl
| |
IBPP::WrongType |
\ |
IBPP::WrongTypeImpl
*/
来自 ibpp.h（两个 fbclient dll 集都识别这些 classes）
/* IBPP never return any error codes. It throws exceptions.
* On database engine reported errors, an IBPP::SQLException is thrown.
* In all other cases, IBPP throws IBPP::LogicException.
* Also note that the runtime and the language might also throw exceptions
* while executing some IBPP methods. A failing new operator will throw
* std::bad_alloc, IBPP does nothing to alter the standard behaviour.
*
* std::exception
* |
* IBPP::Exception
* / \
* IBPP::LogicException IBPP::SQLException
* |
* IBPP::WrongType
*/
在所有 tests.cpp 中，IBPP::SQLException 的唯一问题是在 Test3() 中。每隔一个 catch 使用 IBPP::Exception.
所以这个问题只会在编译 64 位时出现在 Test3() 中，但我认为只要在 64 位实现中使用 IBPP::SQLException 它就会出现。
经过大量研究，我找到了原因。我错误地认为 x86 和 x64 中的异常处理不同。 IBPP 库包含一个错误（自 10 年以来！），它只在 x64/windows szenario 中发生，当 firebird 库向调用者报告一个（复杂的）错误条件时。
那么会发生什么：
测试程序调用 IBPP 库。 IBPP 库调用 firebird API/ 库。 firebird 库在长数组 [20] 中报告其调用结果，他们称之为 "ISC_STATUS vector"。 IBPP 库检查此结果，如果出现错误，它会抛出异常。测试程序捕获此类异常并报告给用户。
到目前为止，还不错。但问题是，IBPP 将 ISC_STATUS 定义为 longs 的数组 [20]，就像火鸟一样，它在 v2.0 之前也是如此——它只支持 x86 windows。从 v2.1 开始，firebird 支持 x64 windows 并将 ISC_STATUS 定义为 intptr_t 的数组，这会导致 "long long" on windows x64 LLP64 编译器并继续LP64 linux 编译器 - 都是 64 位宽。在 ILP32 windows 和 linux x86 编译器上 intptr_t 是 32 位宽。 IBPP 并没有缩小与 firebird 的差距，而是一直保持其对 ISC_STATUS 的定义——这导致 LLP64 windows x64 系统上的数据类型为 32 位（但在 [=53 上为 64 位） =]，因为 linux 上的 gcc 使用 LP64 系统，所以错误只发生在 windows)。
所以 firebird x64 API 向 64 位整数的 "by reference parameter" 数组 [20] 报告最多 20 个状态整数。 FBPP 库传递一个 32 位整数数组 [20]。当 firebird API 将值存储在数组的后半部分时，它会覆盖调用者的内存。在这种情况下，ISC_STATUS 向量之后的下一个字节由 C++ 字符串对象占用。状态数组和字符串都是 IBS（interbase status）class 的一部分。许多 IBPP 函数经常实例化此 class 的本地对象以管理 firebird API 结果和错误描述字符串。当函数退出时，框架会清理此类本地对象并尝试释放字符串，但它在内存中的元数据已被 firebird 覆盖API。
所以本地IBS对象的清理导致了一个未知的软件异常，它过度驱动了IBPP框架抛出的异常。而且这个异常不是被测试程序捕获的，而是被 windows / dr.华生.
我将 ISC_STATUS 的定义从 "long" 修改为 "intptr_t"，并且一切正常。
谢谢大家的指点。