在Solaris上没有创建hs_err_pid.log文件并从jvm转储核心

Question

问题描述

经过一段时间运行我的Java服务器应用程序后,我在Solaris上遇到了Oracle Java虚拟机的奇怪行为.通常,当jvm hs_err_pid.log文件发生崩溃时(位置由-XX:ErrorFilejvm参数确定,如下所述:如何禁止创建hs_err_pid文件？

但在我的情况下,文件没有创建,唯一剩下的是core核心转储文件.

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

试过的解决方案

• 试图找到hs_err_pid.log整个文件系统中的所有文件,但找不到任何文件(甚至在应用程序工作目录之外).即:

  find / -name "hs_err_pid*"

• 我试图找到与jvm相关的jvm错误,但我找不到类似于这种情况的有趣内容.

• 问题看起来有点类似于:Java VM:1.6.0_17和1.6.0_18都可重现SIGSEGV,如何报告？但我仍然无法确认这一点,因为hs_err_pid.log文件丢失了,当然OS平台也不同了.
• (编辑)正如在分析java核心转储问题的工具的答案之一中所建议的那样,我已经从core文件中提取了堆转储jmap并使用Eclipse MAT进行了分析.我发现了一个泄漏(添加到HashMap的元素,在核心转储1,4 M元素时永远不会被清除).然而,这并不能解释为什么hs_err_pid.log没有生成文件,也没有jvm崩溃.
• (EDIT2) 正如Darryl Miles所建议的那样,-Xmx限制已被检查(测试包含的代码无限期地将对象添加到a LinkedList):
  • java -Xmx1444m Test结果java.lang.OutOfMemoryError: Java heap space,
  • java -Xmx2048m Test结果java.lang.OutOfMemoryError: Java heap space,
  • java -Xmx3600m Test 核心转储的结果.

这个问题

有没有人遇到类似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 args:

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

如果您发现某些信息丢失,请发表评论,我会尝试添加它们.

Answer 1

6.0_11 已经很旧了，我最近没有使用过，真的建议升级...

然而，本机代码中的 stackoverflow 可能不会发生故障转储，即以非常低的堆栈调用某些本机函数（例如 FileOutputStream 的 write，套接字使用相同的 impl）。因此，即使 JVM 尝试写入文件，堆栈也不够，写入代码也会崩溃。第二个 stackoverflow 只是拯救了这个过程。

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