故障排除
请注意，并非下面所有任务都需要完成。有些问题仅通过执行几项任务就可以解决。

快速链接

• 为什么发生此问题？
• 从下列平台上的核心文件获取信息：
• Solaris
• Linux
• HPUX
• AIX
• Windows
• 如果没有调试器，怎么办？
• 应针对核心文件的生成而检查的操作系统值
• 停止 JVM 进行 Thread Dump
• 联机调试器指南

1. WebLogic Server 性能包。WebLogic Server 性能包是本地代码，如启用则可能会产生这类错误。禁用此功能以确定这是不是引起问题的原因。可以通过控制台或命令行来执行此操作。，使用控制台来查看“Server”选项卡，将 NativeIOEnabled 设置为 false。请参阅“启用性能包”部分来获得在控制台中的“Server”选项卡下的确切操作步骤顺序。对于 WLS 8.1，这将位于以下网址：http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html#1142800   操作步骤为：
   a.  启动管理服务器（如果它还没有运行）。
   b.  访问该域的管理控制台。
   c.  展开左边窗格中的服务器节点，以显示域中配置的服务器。
   d.  单击要配置的服务器实例的名称。
   e.  选择“Configuration”－>“Tuning”选项卡。
   f.  如果未选中“Enable Native IO”复选框，请选中该复选框。
   g.  单击“Apply”。
   h.  重新启动服务器。

   您也可以通过 WebLogic Server 的启动命令的 java 选项来执行此步骤。在命令行中设置 -Dweblogic.NativeIOEnabled=false，然后启动服务器。命令行将优先于通过控制台发送的命令。

2. 任何 2 类 JDBC 驱动程序都要利用本地 DBMS 库，这些库也会产生这类错误。切换到纯 java（4 类）JDBC 驱动程序，以确定这是不是出错原因。

3. 用 JNI 调用访问的任何本地库也会引起这类错误。如果应用程序使用这些库，则必须仔细检查它们。可能很难排除这些库的问题，因为可能不太容易从应用程序中删除其功能。可能需要进行大量的记录，来确定某个使用模式是否能与核心转储/Dr Watson 错误相关联。

4. JVM 本身是一个本地程序，可能会引起这类错误。当有疑问时，可尝试使用其它认证的 JVM 和/或更新版本，以确定是否由 JVM 错误导致故障。很多 JVM 错误涉及到 JIT 编译器的使用，禁用此功能通常会解决这类问题。一般可通过提供 -Djava.compiler=none 命令选项来实现此目的。

5. 有时候，JVM 将产生一个小日志文件，其中可能包含说明内核来自哪一个库的有用信息，但有时也并非如此。该文件产生于启动 WebLogic Server 的目录中，且其形式为 hs_err_pid<PID #>.log，其中 <PID #> 是 WebLogic Server 进程的进程 ID。

如果在执行这些步骤后，您不能确定错误的原因，则可以检查在启动 WebLogic Server 的目录中产生的核心文件。 您必须从二进制核心文件获得准确的堆栈跟踪来查明产生内核信息的原因。为此，可以像在本“诊断模式”所概述的那样运行一个调试器，例如 dbx 或 gdb，这取决于您的操作系统。

返回页首

1. 执行 file <full path>/core来验证该核心文件是否来自 Java VM。

2. 按如下方式使用 dbx 或 gdb 获取堆栈跟踪。利用 gdb，您可以获得更多有用的信息。Sun 技术支持部门推荐使用 dbx(1) 执行核心文件分析。如果您没有获得 dbx 许可产品，可以从 Sun 下载一个 30 天的试用版本，其中 dbx 打包在 http://wwws.sun.com/software/sundev/buy.html 中。

如果“没有”生成核心文件，那么原因可能在于文件权限问题或核心文件本身的实际限制。核心转储文件的大小可能受下列因素的影响：

• 检查 ulimit -a以查看您的环境是否允许生成核心文件。
• ulimit -c （这是核心文件的大小限制。用 ulimit -c unlimited 调整其大小）。
• 内核限制（ulimit -c的硬极限）。
• 用户的可用磁盘空间（例如，是否有磁盘容量限额？）。
• 另请参阅：应针对核心文件的生成而检查的操作系统值

如果生成了一个核心文件，则对该核心文件运行 dbx 或 gdb。下面用 gdb 产生的一个输出示例说明用于 dbx 和 gdb 的命令。（备注：DEBUG_PROG 是一个环境变量，它允许您指定使用 java 时要启动的调试器或探查器。）

这些命令获得所执行的最后一个线程的堆栈跟踪（where 命令）并显示核心文件中的所有线程的状态（threads命令）。

1. 执行 file <full path>/core 来验证该核心文件是否来自 Java VM。
2. 确保您正在 Linux 上使用 GNU 提供的最新 GDB 版本，以避免任何已知的缺陷。
   
3. 参见： http://ftp.gnu.org/gnu/gdb/
4. 另外确保在 Linux 上为核心文件设置了 ulimit。（例如，ulimit -c unlimited）。
5. 在 Linux 上，缺省为在所有系统上关闭核心转储。在 RedHat Advanced Server 2.1 中，则应在 /etc/security 下。应该有一个名称为 limits.conf 的文件。此文件本身是自解释的，查找单词“core”。如果设置为 0，则禁用了核心转储。
6. 另请参阅：应针对核心文件的生成而检查的操作系统值
7. 使用 gdb 按如下方式获得堆栈跟踪（与此前操作相同）：

ADB：
通过执行下列操作，应能获得堆栈跟踪：

1. 如果 gdb 可用，并且如果产生了实际的二进制核心文件，则遵循前面针对 gdb 所述的操作信息：

2. 但是，AIX 上的 JVM 通常打印出一个 javacore<PID>.<ID Number>.txt 文件，用于调试应用程序。其中包含一些很有用的信息，并且其将显示发生信息转储时正在执行的当前线程。例如，下列信息将指出您创建的 displayHelloWorld() 本地方法中发生的问题。查看本地代码以确定为什么发生核心转储。

3. 查找“当前线程细节”，它将为您提供关于该问题的意见。例如，以下信息说明内核信息来自 ExecuteThread 24，但此时 JVM 正在执行一些 JIT。因此，这看起来像是 IBM 提供的此 JVM 版本上的 JIT 编译器的问题。

Current Thread Details
    "ExecuteThread: '24' for queue: 'default'" sys_thread_t:0x781
        Native Stack
          at 0xD0F15924 in get_invoke_op
          at 0xD0F1535C in resolve_a_method
          at 0xD0F1E610 in resolve_method_call_graph
          at 0xD0F29C40 in jit_compiler_entry
          at 0xD0F2A404 in _jit_fast_compile

1. drwtsn32.log 文件类似于 Unix 上的核心文件。在 Windows 2000 上，这些文件位于以下目录中：C:\Documents and Settings\All Users\Documents\DrWatson。在输入 drwtsn32 ? 后，将出现 Dr. Watson for Windows 2000 框。DrWatson 日志文件概述选项将显示一个屏幕，其中说明了 drwtsn32.log 文件的格式。
2. 也可能从 JVM 本身产生 hs_err_pid<#>.log文件，其中包含了一些有用的信息。

启用/禁用 Dr. Watson：
缺省情况下，在安装 Windows NT 时将启用 Dr. Watson。

1. 检查下面的注册表项，以确保启用了 Dr. Watson（0 为启用，1 为禁用）：

2. 有一个名为“Auto”的条目，它决定了将如何启动 Dr. Watson。这将在 Debugger 注册表值下决定启动哪个调试器或应用程序。
   
3. 对于 Dr. Watson，Debugger 值应包含：

drwtsn32 -p %ld -e %ld -g

1. 如果您不能访问调试器，请查验您的操作系统中是否有 pstack 和 pmap实用程序。
   
2. 如果您拥有这些实用程序（在某些操作系统上，您必须单独下载这些实用程序），可以对系统核心文件运行这些命令，以收集支持所需信息。
   

从 pstack 输出可注意到，出现错误的地址是 e9f90420。pmap输出片段说明 e9f90420 位于 E9F90000 和 E9FA0000 之间，因此该错误是出现在 libhello.so共享对象内的某处。

返回页首

1. 分别在系统级和用户级检查 ulimit -c（配置的核心文件大小）。
2. 检查用户的可用磁盘空间（例如，是否有磁盘容量限额？）。
3. 此外，检查以下参数，在 Solaris 上，该参数在 /etc/system 文件中，并可用其来禁用核心文件：set sys:coredumpsize=0
4. 在 Linux 上，缺省为在所有系统上关闭核心转储。在 RedHat Advanced Server 2.1 中，其应在 /etc/security下。应该有一个名称为 limits.conf 的自解释文件，并查找单词“core”。如果设置为 0，则禁用了信息转储。
5. 更改 HP OS 设置内核参数 maxdsiz（max_per_proc_data_size，此参数增加用户进程数据段大小。），从原来的值（如 64M）改为更大的值（如 134M）。

返回页首

停止 JVM 进行 Thread Dump
您可以设置下列标志，以便在生成核心文件之前对服务器进行 Thread Dump，以得到此时刻的线程状态：

Sun JVM
在 SUN JVM 上，该选项是 -XX:+ShowMessageBoxOnError（在 SUN 网站上没有正式记载）。当 JVM 崩溃时，程序将提示：您想要调试此问题吗？然后您可以进行 JVM Thread Dump。 

JRockit JVM
当发布 JRockit 的 8.1 SP2 版 Service Pack 时，将在该版本中提供相应的选项。该选项在 JRockit 中是 -Djrockit.waitonerror。

返回页首

联机调试器指南

是否需要更多帮助？

如果您已经理解这个模式，但仍需要其它帮助，您可以：

1. 在 http://support.bea.com 上查询 AskBEA（例如使用“core file”），以查找其它已发布的解决方案。
2. 在 http://support.bea.com 上，向 BEA 的某个新闻组中提出更详细具体的问题。

如果这还不能解决您的问题，并且您拥有有效的技术支持合同，您可以通过登录以下网站来打开支持案例：http://support.bea.com。

反馈

请给我们提供您的意见，说明此支持诊断模式“二进制核心文件分析”一文对您有如何帮助，您需要的任何解释，以及对支持诊断模式的新主题的任何要求。

免责声明：

依据 BEA 与您签署的维护和支持协议条款，BEA Systems, Inc. 在本网站上提供技术技巧和修补程序供您使用。虽然您可以将这些信息和代码与您获得 BEA 授权的软件一起使用，但 BEA 并不对所提供的技术技巧和修补程序做任何形式的担保，无论是明确的还是隐含的。

本文档中引用的任何商标是其各自所有者的财产。有关完整的商标信息，请参考您的产品手册。