工具 - Oracle Solaris Studio 12.3 发行版的新增功能

工具

dbx

已知的 dbx 问题和解决方法

当 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)，则由于收集器和程序同时使用定时器，可能会使基于时钟的分析实验中断。
dbx 在调试 Java 代码时可能会崩溃

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

解决方法：
- 请勿执行上述任何操作。
- 在执行上述任何操作前，请删除所有监视（显示）。
dbx 在重新调试 Java 代码时崩溃

在 Java 代码的一行内发出两条 debug 命令可能会导致 dbx 崩溃。
调试应用程序的 J2SE 不同于最初构建应用程序的 J2SE 时，dbx 会抛出异常。

如果您在一个版本的 J2SE 技术下构建了应用程序，又在另一个不同发行版的 J2SE 下调试此应用程序，dbx 会抛出异常。
由于 RTC 预监视分配而报告伪 RUA 错误

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

dbx 限制和不兼容情况

Oracle Solaris Studio 12.3 dbx 有以下限制：

不能从 .dbxrc 文件连接至正在运行的进程。.dbxrc 文件不应含有执行代码的命令。但是，您可以将此类命令放在一个文件中，然后使用 dbx source 命令来执行该文件中的命令。
dbx 无法正确地取消改编指向使用 -compat=4 选项编译的成员函数的指针。对于 -compat=5 选项不会发生此问题。

注 - 此发行版中已删除了 -compat=4 选项。有关详细信息，请参见C++ 编译器。
在 SPARC V9 (-m64) 系统中，使用 call 命令或输出函数调用对作为参数或返回值的嵌套小结构不起作用。
使用 libC.so.5 或者 libC.so.4 的旧副本可能会在 C++ 异常区域中引起 dbx 问题。可能会出现关于错误的 stab 和未处理的异常等警告消息。

解决方法：在所有系统上安装最新的 libC.so.5。
Fortran 用户应该用 -stackvar 选项进行编译，以便充分利用运行时检查。
某些程序可能无法正常使用 -stackvar 选项。在这种情况下，请尝试使用 -C 编译器选项，它将在不使用运行时检查的情况下启用数组下标检查。
对于多线程的应用程序，跟踪派生可能不可靠。
使用 call 或输出函数调用可能会导致多线程应用程序发生死锁。
如果文件是预编译的头文件 (Pre-Compiled Header, PCH) 集合的一部分，请不要使用 dbx 的修复并继续功能来更改头文件。
dbx 命令行解释器是旧版本的 Korn shell (ksh)，不支持代码集独立 (Code Set Independence, CSI)。当在 dbx 命令行上键入多字节字符时，会发生解释错误。
Linux OS 上不能使用以下 dbx 功能：
- 修复并继续功能
- 收集性能数据
- 在下列事件中设置断点：
  - fault
  - lastrites
  - lwp_exit
  - sysin
  - sysout
  - sync
  - throw
- Java 调试
- 调试 32 位程序（除非使用 -x exec32 选项启动 dbx）。
在 Linux 平台上调试程序时可能会发生下面的问题：
- 在调用 exec() 时，dbx 无法跟踪 Linux 平台上的派生进程，或更改为新程序
- Korn shell 中的管道操作符仅限于 Linux 平台。任何需要访问目标进程的 dbx 命令不能作为管道的一部分使用。例如，下面的命令可能会导致 dbx 挂起：
```
where | head -1
```
  解决方法：
  - 按 Ctrl-C 组合键以显示新的 dbx 提示符。
  - dbx 可缓存大量信息，对于上述示例，下列命令序列会起作用：
```
where
where | head —1
```
- 如果程序使用 clone() 实现自己样式的线程，则 dbx 中提供的线程支持不能正确识别这些线程。
  
  解决方法：
  
  使用 libthread.so，而不是 clone()。
- Linux 操作系统中的线程库使用 SIGSTOP 信号作为其内部机制的一部分。通常，dbx 会对您隐藏这些信号，并允许您通过其他源监视真正的 SIGSTOP 信号。偶尔，Linux 操作系统会以意想不到的方式使用 SIGSTOP，dbx 将系统生成的 SIGSTOP 解释为用户生成的 SIGSTOP。
  
  解决方法：
  
  使用 ignore 命令告知 dbx 不要捕获 SIGSTOP 信号。
- 有时线程退出，但 Linux 操作系统并不将退出行为报告给 dbx。
  
  当线程退出，但是未报告此退出操作时，dbx 会等待永远不发生的事件并且不显示新的提示符。这种情况最可能发生在您在 dbx 中提供了 cont 命令之后，但它也可能发生在 step up 命令、step 命令、next 命令和其他命令之后。
  
  解决方法：
  - 有时，键入 Ctrl+C 组合键会导致 dbx 停止等待并显示新的提示符。
  - 如果 Ctrl+C 组合键不起作用，请退出 dbx 并重新启动。
dbx 不支持 GNU C 和 C++ 编译器的下列功能：
- VL 数组
- 异常处理
- OpenMP
- RTTI
- 模板定义
- 缺省参数
- using 指令
- friend
Oracle Linux 6 上的 dbx 存在以下问题：
- 系统库中使用的间接引用符号有时会导致 dbx 在引用处不是实际函数处设置断点。
- 在调试使用 gcc 4.4.4 编译器编译的代码时：
  - 在输出可变长度数组时 dbx 可能会挂起。
  - 在函数结尾处（} 行）停止时 dbx 无法查看局部变量。
  - dbx 不查看使用- D 编译器选项定义的宏。

性能分析器

本节介绍性能分析器工具的已知问题。

有时 "Callers-Callees"（调用方-被调用方）标签会显示一个截断的度量值。
在 SPARC T4 处理器上可能会高估 icache 延迟时间。
OMP 任务和 OMP 并行区域的 OpenMP 等待度量不会累加到 <Total> 的 OpenMP 等待度量中，因为在第一个并行区域项之前的任何分析数据包都不会计算成任何任务或区域的 OMP 等待时间，而是计入总计值。
有时不能正确处理添加和删除实验；解决方法是先装入所有实验，然后进行过滤以排除要去掉的实验。
有时不能正常移动标签。
有时不能正常选择标签中的多个项目。
分析器有时在 SummaryDisp.updateSummary(SummaryDisp.java:249) 处挂起
在 "Source-Disassembly"（源-反汇编）标签上做出选择时 "Summary"（摘要）标签不会更新。
即使存在非零度量时，也可能不显示 "Source"（源）标签的边界中的突出显示。
共享对象的 "Show/Hide/API-only"（显示/隐藏/仅 API）功能有时无法与过滤正常配合使用。使用 er_print 查看实验数据时也会出现此问题。
"Manage Filters"（管理过滤器）对话框的 "General"（常规）标签中的 "Apply"（应用）按钮有时不能应用更改。多按几次 "Apply"（应用）也许会起作用。一个更可靠的解决方法是从 "Timeline"（时间线）、"Threads"（线程）和 "CPUs"（CPU）数据标签的上下文菜单中访问过滤器。
在 "Timeline"（时间线）标签中，"Threads"（线程）和 "CPUs"（CPU）可能并未按数字顺序显示。

collect 实用程序

本节介绍了 collect 实用程序和数据收集的已知问题。

对于某些经过优化的代码，有时不能在 Sandy Bridge 计算机上正确地展开堆栈。
由于 JDK 1.7 中锁定算法的实现方式有所更改，Java 程序上的同步跟踪会双倍计算所有 Java 同步事件。解决方法是将报告的值除以二。
在 Linux 系统中，多线程应用程序的时钟分析所报告的线程数据不精确。内核并不总是按指定的间隔将分析信号传送到每个线程；有时，信号传送到了错误的线程。如果可用，请利用使用 cycle 计数器的硬件计数器分析，以获得更精确的每个线程的结果。
在具有多个以不同时钟频率运行的 CPU 的系统上，时钟分析将基于一个 CPU 的时钟速率生成事件，这可能会导致多算或少算其他 CPU 上的事件。

线程分析器

本节介绍线程分析器的已知问题。

如果下列所有条件均为真，线程分析器可能会发生运行时失败：

在使用 discover 进行过数据争用检测的二进制文件上运行 collect
运行所在的计算机上安装了支持硬件能力过滤器的 SPARC 处理器（如 UltraSPARC T2）
计算机正在运行 Solaris 10 Update 9 或更早的更新

要避免此问题，应在运行 collect 之前，设置环境变量 LD_NOAUXFLTR=yes 以跳过装入过滤器库。由于没有使用过滤器，性能可能会受一些影响。

er_kernel 实用程序

本节介绍 er_kernel 实用程序的已知问题：

er_kernel 有时会导致运行它的计算机崩溃。此问题仅在 UltraSPARC T1、T2 和 T2+ 芯片上运行的 Oracle Solaris 10 上出现过，是因虚拟机管理程序错误而引起的。
er_kernel 分析有时会错误地认定 CPU 状态，不能正确地报告用户数据。
有时一个或多个 CPU 会停止生成 er_kernel 事件，持续时间达 30 秒或更长。
用户进程的 DTrace 堆栈展开有时会遗漏一个帧，通常在叶函数执行到其函数序言或函数尾声时发生。
在具有多个以不同时钟频率运行的 CPU 的系统上，er_kernel 分析将基于一个 CPU 的时钟速率生成事件，这可能会导致多算或少算其他 CPU 上的事件。

IDE

本节介绍 IDE 中的已知问题。

版本控制框架无法以完全远程模式运行。(195121)

版本控制框架通常按照 java.io.File 运行，因此无法创建能够处理远程文件对象的插件。

解决方法：通过 ssh 直接在远程主机上使用版本控制工具。
在某些使用 GDB 7.2 的平台上，"Step Over"（步过）的行为有时像 "Continue"（继续）一样。(200196)

解决方法：尝试较早的 GDB 版本，或在 "Project Properties"（项目属性）的 "Run"（运行）部分中将 "Console Type"（控制台类型）从 "Internal Terminal"（内部终端）更改为其他选项。
内存访问错误工具对远程项目不起作用。(7109562)

如果您在远程主机上创建了一个项目，然后检测项目并对其运行内存分析，则您可能会收到错误消息 " can't execute: discover: No such file or directory"（无法执行: discover: 没有这样的文件或目录）。
单击 "Debugger Console"（调试器控制台）标签不会将焦点设置到调试器命令提示符处。(7102076)

解决方法：再次单击此标签设置焦点，以便在提示符处输入命令。
使用二进制文件新创建的完全远程项目不显示在 "Projects"（项目）标签中。(7110094)

如果正在运行 IDE 桌面分发，并使用远程主机上的现有二进制文件创建项目，新创建的项目不会显示在 "Projects"（项目）标签中。

解决方法：选择 "File"（文件）> "Open Remote C/C++ Project"（打开远程 C/C++ 项目），然后选择要打开的项目。
无法使用 SPARC 平台上的二进制文件创建完全远程项目，因为系统不能识别二进制文件。(7109551)

如果正在运行 IDE 桌面分发，并使用 SPARC 平台的远程主机上的现有二进制文件创建项目，然后选择 "File"（文件）> "Open Remote C/C++ Project"（打开远程 C/C++ 项目），则系统不能识别二进制文件。如果将文件选择器中的过滤器设置为 "All Binaries"（所有二进制文件），则不会显示二进制文件；如果将过滤器设置为 "All Files"（所有文件），则可以选择二进制文件，但会收到消息 "Binary file not found"（找不到二进制文件）。

dmake

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

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

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

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

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

% /usr/sbin/ping $HOST

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

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

       % which dmake
       % which rxm
       % which rxs

远程登录（rsh 或 ssh）每一台主机时不需要输入口令，并且每次远程登录所花费的时间处于可接受的范围（小于 2 秒钟）。

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

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

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

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

可从每台主机获取生成区域 (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 是生成区域的完整路径。

可从每台主机获取 $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 或 ssh 在生成服务器上远程执行命令。
必须能够从生成服务器访问安装了 dmake 软件的 bin 目录。缺省情况下，dmake 会假设生成服务器上 dmake 可执行文件的逻辑路径与 dmake 主机上的路径相同。您可以通过在运行时配置文件中将路径名称指定为主机条目的属性来覆盖此假设。
文件 /etc/opt/SPROdmake/dmake.conf 位于主机上且可读，其中包含正确的信息。如果此文件不存在，dmake 将仅在此系统上分发一个作业。

跳过导航链接
退出打印视图
	Oracle Solaris Studio 12.3 发行版的新增功能 Oracle Solaris Studio 12.3 Information Library (简体中文)

工具

dbx