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

问题描述

运行java服务器应用程序一段时间后，我在Solaris上体验到Oracle java虚拟机的奇怪行为。通常，当jvm崩溃时，会创建

hs_err\u pid.log

文件（位置由

-XX:ErrorFile

jvm参数确定，如下所述：

但在我的例子中，文件没有创建，只剩下

core

core转储文件

使用

pstack

和

pflags

标准Solaris工具，我能够从

core

文件中收集有关崩溃的更多信息（包括在下面）

尝试过的解决方案

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

• 试图在整个文件系统中查找所有

  hs\u err\u pid.log

  文件，但找不到任何文件（即使在应用程序工作目录之外）。例如：

  find/-name“hs\u err\u pid*”

• 我试图找到与jvm相关的jvm bug，但找不到任何与此类似的有趣的东西

• 问题看起来有点类似：但我仍然无法确认这一点，因为缺少

  hs\u err\u pid.log

  文件，当然操作系统平台也不同
• （编辑）正如问题的一个答案中所建议的，我使用

  jmap

  从

  core

  文件中提取了堆转储，并使用Eclipse MAT对其进行了分析。我发现了一个漏洞（在核心转储1,4 M个元素时，添加到HashMap的元素永远不会被清除）但是，这并不能解释为什么没有生成

  hs\u err\u pid.log

  文件，也不能解释jvm崩溃的原因
• （EDIT2）正如Darryl Miles建议的那样，-Xmx限制已被检查（测试包含无限期地将对象添加到

  链接列表的代码）

  ：

  • java-Xmx1444m测试

    带有

    java.lang.OutOfMemoryError的结果：java堆空间

  • java-Xmx2048m测试

    带有

    java.lang.OutOfMemoryError的结果：java堆空间

  • java-xmx360m测试

    核心转储的结果

问题

是否有人在jvm中遇到过类似的问题，以及如何在这种情况下继续查找实际发生的情况（即，在什么情况下，内核从jvm中转储，并且没有创建

hs\u err\u 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

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

使用的jvm参数：

# 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

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

---

如果您发现缺少某些信息，请发表意见，我将尝试添加这些信息。

6.0\u 11非常旧，而且我最近没有使用过，我真的建议在那里升级

但是，本机代码中的stackoverflow可能不会发生崩溃转储，即以非常低的堆栈调用某些本机函数（如写入FileOutputStream，套接字使用相同的impl）。因此，即使JVM尝试写入文件，堆栈仍然不足，写入代码也会崩溃。 第二个stackoverflow只是使进程退出

---

我在一个生产系统上也有类似的情况（没有创建文件），跟踪它不太好，但上面解释了原因。

根据我上面的评论。我认为这个问题是由于设置了太高的a-Xmx值，导致32位地址空间中的可用堆用完了。这迫使内核监控限制（通过拒绝对新内存的请求），JVM才能对其进行监控（通过使用受控的OutOfMemoryException机制）。不幸的是，我不知道Intel Solaris的具体情况，无法了解该平台的预期效果

但是作为Windows的一般规则，最大-Xmx可能是1800M，然后每个额外创建的应用程序线程将其减少16M以及线程本地存储等其他每线程计费问题。此计算的结果应为您提供Java VM在操作系统使用2G/2G拆分（用户/内核）的任何32位进程上的实际可用堆空间的近似值

WinXP和更高版本可以在内核上使用/3G开关来获得更高的分割（3G/1G用户/内核），Linux有一个/proc//map文件，允许您精确查看给定进程的进程地址空间布局（如果您正在运行此应用程序，您可以随着时间的推移将其视为[堆]增长以满足来自DSOs的.text/.rodata/.data/etc.的共享文件映射。这将导致内核拒绝增长堆的请求

这个问题在64位时就消失了，因为要使用的地址空间太多了，在堆遇到其他映射之前，您将耗尽物理和虚拟（交换）内存

---

我相信Solaris上的“truss”会显示一个brk/sbrk系统调用，该调用在核心转储之前不久返回了一个错误代码。标准本机库的某些部分被编码为从不检查新内存请求的返回代码，因此可能会导致崩溃。

启动目录和/或当前工作目录是否可写由JVM造成的？您认为崩溃的原因是对象过多的内存泄漏，因此出现任何corefile都是不寻常的，因为会出现一个优雅的OutOfMemoryError。除非出现一些JNI错误。崩溃处理程序（写出hs_err_pid*.log的代码）是可能的崩溃。可能对正在运行的进程运行系统调用跟踪，以观察它在其生命周期结束时正在做什么（即，您应该能够看到崩溃处理程序是否崩溃，以及它是否尝试创建任何文件hs_err_pid*.log）。在Linux“strace”上，在Solaris“truss”上，感谢您的回答。我确信工作目录是可写的（这有两个原因：jvm是以root权限运行的，并且在前面是用s编写的