如何理解Java Hotspot错误

8

当JVM崩溃时,它会写入一个错误日志hs_err_pid.log。我想找出是什么导致了JVM崩溃?如何理解这些日志,这个日志是如何排列的,是否有文档记录?我尝试在网络上搜索,但没有结果。

请提供相关URL链接,谢谢。

3个回答

5
除非您在调用本地代码(JNI),否则您的代码中不应该出现JVM崩溃;因此,日志文件中的堆栈跟踪信息可能对大多数开发人员来说并不是很有用。这可能就是为什么它可能没有被记录(至少在外部)的原因。
因此,最好的方法可能是按照错误消息建议提交错误报告。
但是,如果您真的想了解它, Kohsuke's Blog 会提供相关信息。像往常一样。 :)

其他恶意事件可能会导致JVM崩溃。我曾经在同一控制器但不同挂载点上进行文件系统维护时遇到过这种情况。我曾经在停止Tomcat之前替换现有的jar文件时遇到过这种情况。(哎呀)通过Sun Java论坛上的hs_err_pid.log中的信息,我能够推断出这两个原因。 - Stu Thompson
我真的觉得我必须将其评为-1。它不仅仅是链接到一个博客,而且这个博客根本没有给我任何有益的信息来发现为什么我的程序崩溃了。因此,它并没有回答问题。 :/ - Joehot200
链接已失效。 - user1531971

0

首先,找到最顶部的一行,看起来类似于"ntdll.dll+0x2000"。

如果热点发生在您的本地代码(即DLL是您自己的),那么找出如何说服编译器生成一份从DLL偏移量到行号的映射列表。显然,这可能意味着您需要使用新编译的DLL重新运行,并等待问题再次发生。

否则,请查看是否搜索特定行会在Google中出现某些东西,要记住相同的错误可能意味着大量的事情。并查看DLL名称是否看起来像是可识别的东西,例如打印机驱动程序名称、图形驱动程序或其他组件,您可以将其追踪到特定的调用。无论那个组件是什么,您都可以将其升级到一个固定版本,或者避免进行有问题的调用。如果您不确定组件是什么,可能只是需要升级"JVM"——升级至您所在版本的最新更新/次要版本数字可能是一个好主意。

过去我也曾见过JIT编译器中的错误,可以通过告诉它不尝试编译相关方法来暂时解决问题——据我模糊地回忆,在这些情况下,热点错误会提供一些线索,表明它是哪个方法(可能只是Java堆栈的转储),但我没有例子来回忆细节。

0

链接已失效。 - user1531971

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接