工具

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 命令行上键入多字节字符时，会发生解释错误。

性能分析器

如果要在 Linux 上使用 Oracle Message Passing Toolkit 8.2 或 8.2.1，可能需要解决方法。版本 8.1 或 8.2.1c 不需要解决方法，或者如果要使用 Oracle Solaris Studio 编译器，则任何版本都不需要解决方法。

Oracle Message Passing Toolkit 版本号由安装路径指定，例如 /opt/SUNWhpc/HPC8.2.1，或者，您可以按照如下所示键入 mpirun —V 查看输出，其中版本以斜体表示：

mpirun (Open MPI) 1.3.4r22104-ct8.2.1-b09d-r70

如果您的应用程序是使用 GNU 或 Intel 编译器编译的，并且要对 MPI 使用 Oracle Message Passing Toolkit 8.2 或 8.2.1，则要获取 MPI 状态数据，必须使用 -WI 和 --enable-new-dtags 选项和 Oracle Message Passing Toolkit link 命令。这些选项将使可执行文件定义 RPATH 及 RUNPATH，从而可使用 LD_LIBRARY_PATH 环境变量启用 MPI 状态库。

dmake

本节介绍了已知的 dmake 软件问题及可能的解决方法。

如果在分布式模式下使用 dmake 出现任何问题，请验证以下内容：

1. $HOME 环境变量应设置为可访问的目录。

   % ls -la $HOME

2. 文件 $HOME/.dmakerc 存在且可读，并包含正确的信息。

   % cat $HOME/.dmakerc

3. 通过使用 /usr/sbin/ping 命令检查每台主机，确保 $HOME/.dmakerc 文件中提及的所有主机均处于活动状态。

   % /usr/sbin/ping $HOST

   其中，$HOST 是系统的名称，它作为主机列于 $HOME/.dmakerc 文件中。

4. 通过使用 dmake、rxm 和 rxs 命令，验证 dmake 二进制文件的路径是否正确。

   % which dmake % which rxm % which rxs

5. 远程登录 (rsh) 每一台主机时不需要输入密码，并且每次远程登录所花费的时间处于可接受的范围（小于 2 秒钟）。

   % time rsh $HOST uname -a

6. 文件 /etc/opt/SPROdmake/dmake.conf 在每台主机中存在并包含正确的信息。如果此文件不存在，dmake 将仅在此系统上分发一个作业：

   % rsh $HOST cat /etc/opt/SPROdmake/dmake.conf

7. 对于每台主机，dmake 二进制文件的路径是正确的：

   % rsh $HOST `which dmake` % rsh $HOST `which rxm` % rsh $HOST `which rxs`

8. 可从每台主机获取生成区域 (rwx)：

   % cd $BUILD % rm $HOST.check.tmp % echo "Build area is available from host $HOST" > $HOST.check.tmp % rsh $HOST cat $BUILD/$HOST.check.tmp

   其中，$BUILD 是生成区域的完整路径。

9. 可从每台主机获取 $HOME：

   % cd $HOME % rm $HOST.check.tmp % echo "HOME is available from host $HOST" > $HOST.check.tmp % rsh $HOST cat $HOME/$HOST.check.tmp

dmake 限制

您可以将任何计算机作为生成服务器，只要其符合以下要求：

• 对于 dmake 主机（您即将在其中启动生成过程的计算机），您必须在系统不提示输入密码的情况下，能够使用 rsh 在生成服务器上远程执行命令。

• 必须能够从生成服务器访问安装了 dmake 软件的 bin 目录。缺省情况下，dmake 会假设生成服务器上 dmake 可执行文件的逻辑路径与 dmake 主机上的路径相同。您可以通过在运行时配置文件中将路径名称指定为主机条目的属性来覆盖此假设。

• 文件 /etc/opt/SPROdmake/dmake.conf 位于主机上且可读，其中包含正确的信息。如果此文件不存在，dmake 将仅在此系统上分发一个作业。