使用gcore进行核心转储，jmap转换为hprof文件格式失败，并显示错误消息
我们最近遇到了一个JVM崩溃，留下了gcore命令生成的核心转储文件。 我们想看一下文件的内容，找出导致崩溃的确切原因。
使用jmap命令，您应该能够将核心转储文件转换为hprof文件格式的文件，然后您可以使用VisualVM和许多其他工具进行分析。 我试过这个并收到错误信息。 这是我运行的命令（在崩溃发生的同一个框中，使用相同的JVM）：
jmap -dump:format=b,file=dump.hprof /usr/java/jdk1.6.0_16/bin/java core.dump.2878
整个回应是：
> Attaching to core core.dump.8483 from executable /usr/java/jdk1.6.0_16/bin/java, please wait... > Error attaching to core file: Can't attach to the core file
这不是一个非常有用的错误消息。 我想知道它是否是一个权限问题，但是我得到了运行该命令的相同消息，就像运行导致核心转储的JVM一样。 我也想知道核心文件是否已损坏，所以我决定使用gdb来查看是否可以打开核心文件并查看其中的内容。 这就是我得到的：
> gdb GNU gdb（GDB）红帽企业Linux（7.0.1-37.el5_7.1） 许可证GPLv3 +：GNU GPL版本3或更高版本 这是免费软件：您可以自由更改并重新分发它。 在法律允许的范围内，不提供任何担保。 输入“显示复制” 和“显示保修”的详细信息。 此GDB配置为“x86_64-redhat-linux-gnu”。 有关错误报告说明，请参阅： 。 （gdb）core-file core.dump.8483 [新主题2889] [新主题2893] [新主题2894] [新主题2895] [新主题2896] [新主题2904] [新主题2915] [新主题2916] [新主题2917] [新主题2921] [新主题2922] [新主题3175] [新主题3239] [新主题3252] [新主题3258] [新主题3260] [新主题3356] [新主题3509] [新主题3510] [新主题3514] [新主题3523] [新主题3541] [新主题3542] [新主题3543] [新主题4022] [新主题4057] [新主题4058] [新主题4077] [新主题4078] [新主题4079] [新主题4080] [新主题6128] [新主题6140] [新主题6162] [新主题6376] [新主题6389] [新主题6408] [新主题6422] [新主题6429] [新主题6451] [新主题6497] [新主题6513] [新主题6514] [新主题6516] [新主题6517] [新主题6532] [新主题6533] [新主题6665] [新主题6675] [新主题6676] [新主题6687] [新主题6689] [新主题6692] [新主题6706] [新主题6707] [新主题6735] [新主题6736] [新主题7033] [新主题7034] [新主题7056] [新主题7077] [新主题7079] [新主题7080] [新主题7082] [新主题7089] [新主题7090] [新主题7091] [新主题7092] [新主题7103] [新主题7105] [新主题7107] [新主题7108] [新主题7116] [新主题7229] [新主题7308] [新主题7493] [新主题7505] [新主题7510] [新主题7511] [新主题7517] [新主题7523] [新主题7604] [新主题7617] [新主题7618] [新主题7619] [新主题8676] [新主题8693] [新主题8700] [新主题8851] [新主题8860] [新主题8887] [新主题9007] [新主题9118] [新主题9119] [新主题9120] [新主题9413] [新主题9427] [新主题9495] [新主题9508] [新主题9519] [新主题9535] [新主题9536] [新主题9537] [新主题9554] [新主题9556] [新主题9659] [新主题9660] [新主题9663] [新主题9664] [新主题9665] [新主题9666] [新主题9667] [新主题9668] [新主题9669] [新主题9670] [新主题9671] [新主题9678] [新主题9870] [新主题9953] [新主题9998] [新主题10002] [新主题10118] [新主题10119] [新主题10122] [新主题10149] [新主题10152] [新主题10155] [新主题10176] [新主题10178] [新主题10179] [新主题10180] [新主题10182] [新主题10194] [新主题10195] [新主题10196] [新主题10198] [新主题10199] [新主题10200] [新主题10201] [新主题10202] [新主题10203] [新主题10205] [新主题10206] [新主题10244] [新主题10246] [新主题10247] [新主题10248] [新主题10249] [新主题10251] [新主题10252] [新主题10254] [新主题10255] [新主题10256] [新主题10257] [新主题10258] [新主题10259] [新主题10260] [新主题10261] [新主题10262] [新主题10263] [新主题10264] [新主题10265] [新主题10267] [新主题10268] [新主题10269] [新主题10271] [新主题10476] [新主题10477] [新主题10479] [新主题10552] [新主题10607] [新主题10611] [新主题10612] [新主题10613] [新主题10615] [新主题10617] [新主题10623] [新主题10624] [新主题10625] [新主题10641] [新主题10642] [新主题10649] [新主题10736] [新主题10742] [新主题10756] [新主题10758] [新主题10760] [新主题10761] [新主题10762] [新主题11278] [新主题11412] [新主题11513] [新主题11514] [新主题2878] （gdb）退出
那时我放弃了，因为我对gbd一无所知以及如何使用它来诊断这类问题。 我甚至不太明白最后一个命令是做什么的。 值得注意的是，输出中确实存在134个“新线程”行，如果每个线代表JVM中产生的新线程，这可能是JVM死亡的原因。
所以我的问题实际上是三折 –
1）知道为什么jmap命令可能给出了错误消息？
2）任何想法gdb输出意味着什么？
3）任何想法如何使用gdb进一步诊断这个问题？
顺便说一句，jvisualvm可以直接加载核心转储。 但是您必须使用创建核心文件的相同jvm。
核心文件是否大于2GB？ 如果是这样，您可能会遇到JVM附带的libsaproc.so Linux构建问题。
再次运行您的命令，但是像这样：
strace -o out.txt -f $yourOriginalCommand
然后’grep core.2878 out.txt’并在open（）系统调用上查找错误。 它是否返回错误（E_XXXXX）或文件句柄号？
这让我很烦恼，因为我有一个代表我需要分析的堆的核心文件，但我经常看到下面的exception消息：
sun.jvm.hotspot.debugger.NoSuchSymbolException：在任何已知库名称（libjvm.so，libjvm_g.so，gamma_g）中找不到符号“gHotSpotVMTypeEntryTypeNameOffset”
将jre从我的源计算机（获取核心文件的计算机）复制到目标计算机中的完全相同的文件夹，然后运行带有该java位置的jmap作为参数为我工作。
所以这里是尝试以防其他人遇到这种情况的步骤：
1.通过gdb连接到核心文件并确认正在运行的进程正在使用的java二进制文件的位置：
gdb --core=
2.上面的输出将以类似的结尾
[New Thread 22748] **Core was generated by `/opt/blah/location/jre/bin/java -Xmx...'.**
3.确保将匹配的jre版本复制到/ opt / blah / location /目录中
-
然后启动jmap为：
/opt/jdk1.8.0_09/bin/jmap -heap /opt/blah/location/jre/bin/java /path/to/core-file这应该成功连接到核心文件并打印出堆统计信息。 如果是，则表示您已成功读取核心文件
-
从那时起，您可以使用以下命令从核心文件成功生成hprof：
/opt/jdk1.8.0_09/bin/jmap -dump:format=b,file=my-file.hprof /opt/blah/location/jre/bin/java /path/to/core-file