Guys when the JVM Crashes it writes an Error Log hs_err_pid.log. I want to find out what caused the JVM to crash ? How to understand these Logs, is it documented anywhere on how this Log is arranged. I tried to search on the Net but to no avail :-(
当JVM崩溃时,他会写一个错误日志hs_err_pid.log。我想找出导致JVM崩溃的原因?如何理解这些日志,是否记录了日志的排列方式。我试图在网上搜索但无济于事:-(
Pointing out to relevant URL's will be appreciated. Thanks.
指出相关的URL将不胜感激。谢谢。
3 个解决方案
#1
Unless you are calling native code (JNI), nothing in your code should ever make JVM crash; so the stack trace information in that log file is probably not meant to be very useful to most developers. That's probably why it might not be documented (at least externally). So the best thing is probably to file a bug report as suggested by the error message.
除非您调用本机代码(JNI),否则代码中的任何内容都不应该导致JVM崩溃;因此,该日志文件中的堆栈跟踪信息可能并不意味着对大多数开发人员非常有用。这可能是为什么它可能没有记录(至少在外部)。因此,最好的办法可能是提交错误消息所建议的错误报告。
But, if you really do want to understand it, Kohsuke's Blog has the goods. As usual. :)
但是,如果你真的想了解它,Kohsuke的博客就有货。照常。 :)
#2
To start with, look for the topmost line that looks something like "ntdll.dll+0x2000".
首先,查找看起来像“ntdll.dll + 0x2000”的最顶行。
If the hotspot is occurring in your native code (i.e. the DLL is one of yours), then find out how to persuade your compiler to produce a list of mappings from DLL offset to line number. Obviously, that may mean you need to re-run with the newly compiled DLL and wait for the problem to occur again.
如果热点发生在您的本机代码中(即DLL是您的一个),那么请找出如何说服编译器生成从DLL偏移到行号的映射列表。显然,这可能意味着您需要使用新编译的DLL重新运行并等待问题再次发生。
Otherwise, see if searching for that specific line brings up something in Google, bearing in mind that the same error could mean a whole host of things. And see if the DLL name looks like it's something recognisable, e.g. a printer driver name, graphics driver, or some other component that you can track down to a particular call. Whatever that component is, you may be able to upgrade it to a fixed version, or avoid making the call in question. If you're not sure what the component is, it may just be "the JVM" that you need to upgrade-- upgrading at least to the latest update/minor version nubmer of whatever version you're on is probably a good idea.
否则,看看搜索特定行是否会在Google中出现问题,请记住,同样的错误可能意味着一大堆事情。并查看DLL名称是否看起来像是可识别的东西,例如打印机驱动程序名称,图形驱动程序或您可以追踪到特定呼叫的其他组件。无论该组件是什么,您都可以将其升级到固定版本,或者避免拨打相关电话。如果您不确定该组件是什么,它可能只是您需要升级的“JVM” - 至少升级到您所使用的任何版本的最新更新/次要版本nubmer可能是个好主意。
In the past I've also seen bugs in the JIT compiler that can be temporarily solved by telling it not to attempt to compile the particular method in question-- as I recall vaguely, in these cases, the hotspot error gives some clue as to which method it was (possibly just the dump of the Java stack), but I don't have an example to hand to recall the details.
在过去,我也看到了JIT编译器中的错误,可以通过告诉它不要尝试编译有问题的特定方法来暂时解决 - 我隐约记得,在这些情况下,热点错误提供了一些线索,它是哪种方法(可能只是Java堆栈的转储),但我没有一个示例来回忆细节。
#3
this is pretty useful: http://weblogs.java.net/blog/kohsuke/archive/2009/02/crash_course_on.html
这非常有用:http://weblogs.java.net/blog/kohsuke/archive/2009/02/crash_course_on.html
ok the first anwser already mentions this url, nevermind
好的,第一个anwser已经提到了这个网址,没关系
#1
Unless you are calling native code (JNI), nothing in your code should ever make JVM crash; so the stack trace information in that log file is probably not meant to be very useful to most developers. That's probably why it might not be documented (at least externally). So the best thing is probably to file a bug report as suggested by the error message.
除非您调用本机代码(JNI),否则代码中的任何内容都不应该导致JVM崩溃;因此,该日志文件中的堆栈跟踪信息可能并不意味着对大多数开发人员非常有用。这可能是为什么它可能没有记录(至少在外部)。因此,最好的办法可能是提交错误消息所建议的错误报告。
But, if you really do want to understand it, Kohsuke's Blog has the goods. As usual. :)
但是,如果你真的想了解它,Kohsuke的博客就有货。照常。 :)
#2
To start with, look for the topmost line that looks something like "ntdll.dll+0x2000".
首先,查找看起来像“ntdll.dll + 0x2000”的最顶行。
If the hotspot is occurring in your native code (i.e. the DLL is one of yours), then find out how to persuade your compiler to produce a list of mappings from DLL offset to line number. Obviously, that may mean you need to re-run with the newly compiled DLL and wait for the problem to occur again.
如果热点发生在您的本机代码中(即DLL是您的一个),那么请找出如何说服编译器生成从DLL偏移到行号的映射列表。显然,这可能意味着您需要使用新编译的DLL重新运行并等待问题再次发生。
Otherwise, see if searching for that specific line brings up something in Google, bearing in mind that the same error could mean a whole host of things. And see if the DLL name looks like it's something recognisable, e.g. a printer driver name, graphics driver, or some other component that you can track down to a particular call. Whatever that component is, you may be able to upgrade it to a fixed version, or avoid making the call in question. If you're not sure what the component is, it may just be "the JVM" that you need to upgrade-- upgrading at least to the latest update/minor version nubmer of whatever version you're on is probably a good idea.
否则,看看搜索特定行是否会在Google中出现问题,请记住,同样的错误可能意味着一大堆事情。并查看DLL名称是否看起来像是可识别的东西,例如打印机驱动程序名称,图形驱动程序或您可以追踪到特定呼叫的其他组件。无论该组件是什么,您都可以将其升级到固定版本,或者避免拨打相关电话。如果您不确定该组件是什么,它可能只是您需要升级的“JVM” - 至少升级到您所使用的任何版本的最新更新/次要版本nubmer可能是个好主意。
In the past I've also seen bugs in the JIT compiler that can be temporarily solved by telling it not to attempt to compile the particular method in question-- as I recall vaguely, in these cases, the hotspot error gives some clue as to which method it was (possibly just the dump of the Java stack), but I don't have an example to hand to recall the details.
在过去,我也看到了JIT编译器中的错误,可以通过告诉它不要尝试编译有问题的特定方法来暂时解决 - 我隐约记得,在这些情况下,热点错误提供了一些线索,它是哪种方法(可能只是Java堆栈的转储),但我没有一个示例来回忆细节。
#3
this is pretty useful: http://weblogs.java.net/blog/kohsuke/archive/2009/02/crash_course_on.html
这非常有用:http://weblogs.java.net/blog/kohsuke/archive/2009/02/crash_course_on.html
ok the first anwser already mentions this url, nevermind
好的,第一个anwser已经提到了这个网址,没关系