java - 没有创建 hs_err_pid.log 文件，也没有从 Solaris 上的 jvm 转储核心

Question

问题描述

在运行我的 Java 服务器应用程序一段时间后，我遇到了 Solaris 上 Oracle Java 虚拟机的奇怪行为。通常，当 jvm 崩溃时，会创建 hs_err_pid.log 文件(位置由 -XX:ErrorFile jvm 参数确定，如下所述:How can I suppress the creation of the hs_err_pid file?

但在我的例子中，文件没有创建，唯一剩下的是 core 核心转储文件。

使用 pstack 和 pflags 标准 Solaris 工具，我能够从 core 收集有关崩溃的更多信息(包括在下面)文件。

尝试过的解决方案

• 试图在整个文件系统中查找所有 hs_err_pid.log 文件，但什么也找不到(即使在应用程序工作目录之外)。即:

  查找/-name "hs_err_pid*"

• 我试图找到与 jvm 相关的 jvm 错误，但找不到与此案例类似的任何有趣内容。

• 问题看起来有点类似于:Java VM: reproducable SIGSEGV on both 1.6.0_17 and 1.6.0_18, how to report?但我仍然无法确认这一点，因为 hs_err_pid.log 文件丢失，当然操作系统平台也不同。
• (EDIT) 正如 Tool for analyzing java core dump 的一个答案中所建议的那样问题，我使用 jmap 从 core 文件中提取了堆转储，并使用 Eclipse MAT 对其进行了分析。我发现了一个泄漏(添加到 HashMap 的元素，在核心转储 1,4 M 元素时永远不会被清理)。然而，这并不能解释为什么没有生成 hs_err_pid.log 文件，也没有解释 jvm 崩溃的原因。
• (EDIT2) 正如 Darryl Miles 所建议的，-Xmx 限制已经过检查(测试包含无限期地向 LinkedList 添加对象的代码):
  • java -Xmx1444m Test 结果为 java.lang.OutOfMemoryError: Java heap space,
  • java -Xmx2048m Test 结果为 java.lang.OutOfMemoryError: Java heap space,
  • java -Xmx3600m 测试 核心转储结果。

问题

有没有人遇到过与 jvm 类似的问题以及如何在这种情况下继续查找实际发生的情况(即在什么情况下核心从 jvm 中转储并且没有创建 hs_err_pid.log 文件) ？

解决此问题的任何提示或指示都会非常有帮助。

提取的标志

# pflags core
...
/2139095:      flags = DETACH
    sigmask = 0xfffffeff,0x0000ffff  cursig = SIGSEGV

提取的堆栈

# pstack core
...
-----------------  lwp# 2139095 / thread# 2139095  --------------------
 fb208c3e ???????? (f25daee0, f25daec8, 74233960, 776e3caa, 74233998, 776e64f0)
 fb20308d ???????? (0, 1, f25db030, f25daee0, f25daec8, 7423399c)
 fb20308d ???????? (0, 0, 50, f25da798, f25daec8, f25daec8)
 fb20308d ???????? (0, 0, 50, f25da798, 8561cbb8, f25da988)
 fb203403 ???????? (f25da988, 74233a48, 787edef5, 74233a74, 787ee8a0, 0)
 fb20308d ???????? (0, f25da988, 74233a78, 76e2facf, 74233aa0, 76e78f70)
 fb203569 ???????? (f25da9b0, 8b5b400, 8975278, 1f80, fecd6000, 1)
 fb200347 ???????? (74233af0, 74233d48, a, 76e2fae0, fb208f60, 74233c58)
 fe6f4b0b __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_ (74233d44, 74233bc8, 74233c54, 8b5b400) + 1a3
 fe6f4db3 __1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v2468_v_ (fe6f4968, 74233d44, 74233bc8, 74233c54, 8b5b4
00) + 27
 fe6f4deb __1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThread__v_ (74233d44, 8975278, 74233c54, 8b5b400) + 2f
 fe76826d __1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThread__v_ (74233d44, 897526c, fed2d464, fed2d6d0, 7
4233c54, 8b5b400) + c1
 fe76f4fa __1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_ (74233d44, 8975268, 897526c, fed2d464, fed2d6d0, 8b5b
400) + 7e
 fe7805f6 __1cMthread_entry6FpnKJavaThread_pnGThread__v_ (8b5b400, 8b5b400) + d2
 fe77cbe4 __1cKJavaThreadRthread_main_inner6M_v_ (8b5b400) + 4c
 fe77cb8e __1cKJavaThreadDrun6M_v_ (8b5b400) + 182
 feadbd59 java_start (8b5b400) + f9
 feed59a9 _thr_setup (745c5200) + 4e
 feed5c90 _lwp_start (745c5200, 0, 0, 74233ff8, feed5c90, 745c5200)

系统信息:

# uname -a
SunOS xxxx 5.10 Generic_137138-09 i86pc i386 i86pc
# java -version
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Server VM (build 11.0-b16, mixed mode)
# ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 10240
coredump(blocks) unlimited
nofiles(descriptors) 256
memory(kbytes) unlimited

使用的 jvm 参数:

java -Xms1024M -Xmx2048M -verbose:gc -Xloggc:logs/gc.log -server com.example.MyApplication

如果您发现缺少某些信息，请发表评论，我会尽力添加。

Answer 1

6.0_11 很旧，我最近没有使用经验，真的建议在那里升级...

但是，本地代码中的 stackoverflow 可能不会发生崩溃转储，即调用一些具有非常低堆栈的本地函数(如 FileOutputStream 的写入，套接字使用相同的 impl)。因此，即使 JVM 尝试写入文件，但堆栈不足，写入代码也会崩溃。第二个 stackoverflow 只是解决了这个过程。

我在生产系统上确实有类似的情况(没有创建文件)并且跟踪它并不好，但上面解释了原因。