伙计们,当 JVM 崩溃时,它会写入错误日志 hs_err_pid.log。我想找出导致 JVM 崩溃的原因?如何理解这些日志,是否在任何地方记录了该日志的排列方式。我试图在网上搜索但无济于事:-(
指出相关的 URL 将不胜感激。谢谢。
伙计们,当 JVM 崩溃时,它会写入错误日志 hs_err_pid.log。我想找出导致 JVM 崩溃的原因?如何理解这些日志,是否在任何地方记录了该日志的排列方式。我试图在网上搜索但无济于事:-(
指出相关的 URL 将不胜感激。谢谢。
除非您调用本机代码 (JNI),否则代码中的任何内容都不会导致 JVM 崩溃;因此,该日志文件中的堆栈跟踪信息可能对大多数开发人员没有多大用处。这可能就是为什么它可能没有被记录(至少在外部)。因此,最好的办法可能是按照错误消息的建议提交错误报告。
但是,如果你真的想了解它,Kohsuke 的博客有货。照常。:)
首先,寻找看起来像“ntdll.dll+0x2000”的最上面一行。
如果热点出现在您的本机代码中(即 DLL 是您的代码之一),那么请了解如何说服您的编译器生成从 DLL 偏移量到行号的映射列表。显然,这可能意味着您需要使用新编译的 DLL 重新运行并等待问题再次出现。
否则,请查看搜索该特定行是否会在 Google 中显示某些内容,请记住,相同的错误可能意味着很多事情。并查看 DLL 名称是否看起来是可识别的,例如打印机驱动程序名称、图形驱动程序或您可以追踪到特定调用的其他组件。无论该组件是什么,您都可以将其升级到固定版本,或者避免进行有问题的调用。如果您不确定该组件是什么,它可能只是您需要升级的“JVM”——至少升级到您使用的任何版本的最新更新/次要版本可能是个好主意。
在过去,我还看到 JIT 编译器中的错误可以通过告诉它不要尝试编译有问题的特定方法来临时解决——我模糊地记得,在这些情况下,热点错误提供了一些线索它是哪种方法(可能只是 Java 堆栈的转储),但我没有示例可以回忆细节。
这非常有用:http ://weblogs.java.net/blog/kohsuke/archive/2009/02/crash_course_on.html
好的,第一个回答者已经提到了这个网址,没关系