Question

-bash-3.2$ uname -a
SunOS b2s-sol10spr-1 5.10 Generic_147147-26 sun4v sparc sun4v
-bash-3.2$ dbx -V
Sun DBX Debugger 8.0 SunOS_sparc 2014/10/21
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 8.0' in your .dbxrc
(dbx)

我遇到一个奇怪的问题，调试器只是显示函数参数和本地/成员变量的值完全错误。

这是示例回溯

=>[1] SQLGetDiagRecW(HandleType = -28417, Handle = 0x480000000101dfc1, RecNumber = -12288, Sqlstate = (nil), NativeError = 0xffffffff7fffdf, MessageText = 0x9100000001002bbd, BufferLength = -9583, TextLength = 0x380000000101da91), line 3154 in "CInterface.cpp"
  [2] extract_diag_error_w(htype = 3, handle = 0x3, connection = 0x1014d32c0, head = 0x101e5a5e0, return_code = -1, save_to_diag = 0), line 4447 in "__info.c"
  [3] function_return_ex(level = 3, handle = 0x101e5a1a0, ret_code = -1, save_to_diag = 0), line 4863 in "__info.c"
  [4] SQLExecDirectW(statement_handle = 0x101e5a1a0, statement_text = 0x101dacde0, text_length = -3), line 442 in "SQLExecDirectW.c"
  <truncated>

第1帧在有问题的共享库中，而其他帧在unixODBC libodbc.so中

如果我们查看extract_diag_error_w的代码（您可以从http://www.unixodbc.org/unixODBC-2.3.1.tar.gz获取代码，则以下代码段来自DriverManager / __ info.c）

ret = SQLGETDIAGRECW( connection,
                head -> handle_type,
                handle,
                rec_number,
                sqlstate,
                &native,
                msg1,
                sizeof( msg1 ),
                &len );

请注意，我们在其他地方有

#define SQLGETDIAGRECW(con,typ,han,rn,st,nat,msg,bl,tlp)\
                                    (con->functions[77].funcW)\
                                        (typ,han,rn,st,nat,msg,bl,tlp)

在dbx中，如果我转到第2帧并打印head -> handle_type，则得到3，但如果我转到第1帧并打印HandleType，则得到-28417。

如果dbx找不到值（由于优化或w / e，即使此是调试版本），我也希望它告诉我（{{1 }}等。另外，我看到的每个值似乎都是错误的（我已经确认调试器通过控制流对我撒谎，例如<value optimized out>这样的代码，其中dbx声称它是一个负数，但不会引发异常。

有问题的共享库是在另一台机器上构建的（而unixODBC是在本地构建的），所以这可能涉及其中吗？它也是使用gcc构建的，在构建unixODBC时我使用了默认的编译器（尽管我认为它也是g / cc，因为它们都依赖于if (x < 0) throw ...;）

有什么建议吗？（我猜想更新dbx可能有用，但是在这种环境下会很困难。）

编辑：这是一个带有局部变量的示例

libgcc_s.so.1

edit 2：这是麻烦的库的构建方式（需要重建unixODBC，稍后再做）。

用于编译一个.cpp文件的示例命令（我删除了一堆包含目录）

(dbx) next
t@1 (l@1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 64 in file "ODBCStringConverter.cpp"
   64       simba_int32 length = in_length;
(dbx) next
t@1 (l@1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 66 in file "ODBCStringConverter.cpp"
   66       if (0 == in_length)
(dbx) print length
length = 11
(dbx) print in_length
in_length = 419430399
(dbx) next
t@1 (l@1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 73 in file "ODBCStringConverter.cpp"
   73       else if (SIMBA_NTS == in_length)
(dbx) next
t@1 (l@1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 79 in file "ODBCStringConverter.cpp"
   79       simba_int32 bufferBytes = length;
(dbx) next
t@1 (l@1) stopped in Simba::Support::ODBCStringConverter::ConvertWStringToSQLWCHARString at line 80 in file "ODBCStringConverter.cpp"
   80       if (!in_isLengthInBytes)
(dbx) print bufferBytes
bufferBytes = 1744830464
(dbx)

用于链接的命令（删除了一堆.o文件）

/opt/csw/gcc4/bin/g++ -DSIZEOF_LONG_INT=8 -DSQL_WCHART_CONVERT -DHAVE_MEMMOVE -m64 -fPIC -pthread  -Wall -Wno-unknown-pragmas -DSIMBA -D_REENTRANT -DCLUNIX -DNDEBUG -D_POSIX_PTHREAD_SEMANTICS  -O0 -g -D_DEBUG  -c Common/QSTableMetadataFile.cpp -o Common/QSTableMetadataFile_solaris10sparc_gcc4_9_debug64.cpp.o

DBX在使用-g

0 个答案: