dbx

已知的 dbx 问题和解决方法

1. 当 dbx 连接到进程时发生数据收集问题

   如果将 dbx 连接到一个正在运行的进程，但是没有预先装入收集器库 libcollector.so，将发生一系列错误。

   • 无法收集任何跟踪数据：同步等待跟踪、堆跟踪或 MPI 跟踪。跟踪数据是通过对各个库执行插入操作而收集的。如果没有预先装入 libcollector.so，将无法执行插入操作。

   • 如果在 dbx 连接到进程后程序安装了一个信号处理程序，并且该信号处理程序不传递 SIGPROF 和 SIGEMT 信号，则分析数据和抽样数据将会丢失。

   • 如果程序使用异步 I/O 库 libaio.so，则基于时钟的分析数据和抽样数据将会丢失，因为 libaio.so 需要使用 SIGPROF 来执行异步取消操作。

   • 如果程序使用硬件计数器库 libcpc.so，则硬件计数器溢出分析实验将会遭到破坏，因为收集器和程序都在使用该库。如果在将 dbx 连接到进程后装入了硬件计数器库，只要通过广义搜索而不是在 libcpc.so 中搜索来解析对 libcpc 库函数的引用，硬件计数器实验即可顺利进行。

   • 如果程序调用 setitimer(2)，则由于收集器和程序同时使用定时器，可能会使基于时钟的分析实验中断。

2. dbx 在调试 Java 代码时可能会崩溃

   如果从 dbx shell 内部发出一个 cd 命令，或者设置 CLASSPATH 环境变量或 CLASSPATHX 环境变量，dbx 可能会因分段错误而崩溃。

   解决方法：

   • 请勿执行上述任何操作。

   • 在执行上述任何操作前，请删除所有监视（显示）。

3. dbx 在重新调试 Java 代码时可能会崩溃

   在 Java 代码的一行内发出两条 debug 命令可能会导致 dbx 崩溃。

4. 如果调试应用程序与生成应用程序时所用的 J2SE 不同，dbx 会抛出异常。

   如果调试应用程序与生成应用程序所用的 J2SE 技术版本不同，dbx 会抛出异常。

5. 由于 RTC 预监视分配而报告伪 RUA 错误

   在具有多线程程序的不寻常情况下，当运行时检查 (runtime checking, RTC) 检测到对 RTC 开始监视内存分配之前分配的与线程有关的内部数据的访问时，会报告伪 RUA 错误。由于这些情况是正常线程切换行为的一部分，因此可以使用 dbx suppress 命令放心地忽略这些伪 RUA 报告。

dbx 限制和不兼容情况

Oracle Solaris Studio 12.2 dbx 有以下限制：

• 在基于 x86 系统的 Linux 操作系统上，无法使用 dbx 的以下功能：

  • 修复并继续功能

    收集性能数据

    在下列事件中设置断点：

    • fault

      lastrites

      lwp_exit

      sysin

      sysout

      sync

      throw

• 在基于 x64 系统的 Linux 操作系统上，无法使用 dbx 的以下功能：

  • Java 调试

  • 调试 32 位程序（除非使用 -x exec32 选项启动 dbx）。

• 当调用 exec() 时，dbx 无法在 Linux 平台上跟踪派生进程，或对新程序执行更改。

• Korn shell 中的管道操作符仅限于 Linux 平台。任何需要访问目标进程的 dbx 命令不能作为管道的一部分使用。例如，下面的命令可能会导致 dbx 挂起：

      where | head —1

  解决方法：

  • 键入 Ctrl-C 组合键以显示新的 dbx 提示符。

  • dbx 将缓存大量信息，因此，对于上面的示例，您可以使用下面的命令序列：

    where where | head —1

• 在 Linux 平台上调试程序时可能会发生下面的问题：

  • 如果程序使用 clone() 实现自己样式的线程，则 dbx 中提供的线程支持不能正确识别这些线程。

    解决方法：

    使用 libthread.so 而不是 clone()。

  • Linux 操作系统中的线程库使用 SIGSTOP 信号作为其内部机制的一部分。通常，dbx 会对您隐藏这些信号，并允许您通过其他源监视真正的 SIGSTOP 信号。偶尔，Linux 操作系统会以意想不到的方式使用 SIGSTOP，dbx 将系统生成的 SIGSTOP 解释为用户生成的 SIGSTOP。

    解决方法：

    使用 ignore 命令告知 dbx 不要捕获 SIGSTOP 信号。

  • 有时线程退出，但 Linux 操作系统并不将退出行为报告给 dbx。当使用新的线程库 (NPTL) 时，这种情况发生的次数会减少。

    当线程退出，但是未报告此退出操作时，dbx 会等待永远不发生的事件并且不显示新的提示符。这种情况最可能发生在您在 dbx 中提供了 cont 命令之后，但它也可能发生在 step up 命令、step 命令、next 命令和其他命令之后。

    解决方法：

    • 有时，键入 Ctrl+C 组合键会导致 dbx 停止等待并显示新的提示符。

    • 如果 Ctrl+C 组合键不起作用，请退出 dbx 并重新启动。

• C++ 表达式的运行时类型信息不适用于 g++ 编译器编译的程序。

• 不能从 .dbxrc 文件连接至正在运行的进程。.dbxrc 文件不应含有执行代码的命令。但是，您可以将此类命令放在一个文件中，然后使用 dbx source 命令来执行该文件中的命令。

• dbx 无法正确地还原指向 compat=4 的成员函数的指针。如果使用 compat=5，则不会出现此问题。

  解决方法：按如下方法重新编译程序：

  CC —compat=4 —Qoption ccfe —abiopt=pmfun1

  该标志引入了 ABI 更改并且不应该在产品生成中使用。

• 在 SPARC V9 (-m64) 系统中，使用 call 命令或输出函数调用对作为参数或返回值的嵌套小结构不起作用。

• 使用 libC.so.5 或者 libC.so.4 的旧副本可能会在 C++ 异常区域中引起 dbx 问题。可能会出现关于错误的 stab 和未处理的异常等警告消息。

  解决方法：在所有系统上安装最新的 libC.so.5。

• Fortran 用户应该用 -stackvar 选项进行编译，以便充分利用运行时检查。

• 某些程序可能无法正常使用 -stackvar。在这种情况下，请尝试使用 -C 编译器选项，它将在不使用运行时检查的情况下启用数组下标检查。

• 对于多线程的应用程序，跟踪派生可能不可靠。

• 使用调用命令或输出函数调用可能会导致多线程应用程序发生死锁。

• 如果文件是预编译的头文件 (Pre-Compiled Header, PCH) 集合的一部分，请不要使用 dbx 的修复并继续功能来更改头文件。

• dbx 命令行解释器是旧版本的 Korn shell (ksh)，不支持代码集独立 (Code Set Independence, CSI)。当在 dbx 命令行上键入多字节字符时，会发生解释错误。