java 如何解决/调试 JVM 崩溃 (SIGSEGV) 的最佳方法
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/36109313/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Best way on how to solve/debug JVM crash (SIGSEGV)
提问by Philipp
I'm really lost and I don't know how to face and solve my problem. I have a piece of simple Java Code, which leads to a JVM crash:
我真的很迷茫，我不知道如何面对和解决我的问题。我有一段简单的 Java 代码，这会导致 JVM 崩溃：
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00000001057ce9d4, pid=10727, tid=18947
#
# JRE version: Java(TM) SE Runtime Environment (8.0_73-b02) (build 1.8.0_73-b02)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.73-b02 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# V [libjvm.dylib+0x3ce9d4] PhaseIdealLoop::idom_no_update(Node*) const+0x12
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x00007feeef003800): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=18947, stack(0x0000700000ec4000,0x0000700000fc4000)]
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008
I have no idea on how to solve the problem. The program is pretty simple, it receives a message through Kafka and triggers tasks based on the message received. If I add two different tasks, the program crashes after 900 - 1,500 messages. All of the messages are the same and the program does not use any JNI stuff (the used 3rd party libraries don't use any JNI as well, as far as I'm informed).
我不知道如何解决这个问题。该程序非常简单，它通过 Kafka 接收消息并根据接收到的消息触发任务。如果我添加两个不同的任务，程序会在 900 - 1,500 条消息后崩溃。所有消息都是相同的，并且程序不使用任何 JNI 东西（据我所知，使用的第 3 方库也不使用任何 JNI）。
I never faced this problem, but I'd love/need to find a way on how to figure out what the problem is. I already used other versions of the JVM (Java 8.0_66, 8.0_73-b02, and 8.0_74-b02). So what can I do? Thank you so much!
我从未遇到过这个问题，但我很想/需要找到一种方法来找出问题所在。我已经使用了其他版本的 JVM（Java 8.0_66、8.0_73-b02 和 8.0_74-b02）。那我能做什么？太感谢了！
EDIT (1): Sometimes I also get the following error/info:
编辑（1）：有时我也会收到以下错误/信息：
...
# JRE version: Java(TM) SE Runtime Environment (8.0_73-b02) (build 1.8.0_73-b02)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.73-b02 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# V [libjvm.dylib+0x3ce9d4]
...
EDIT (2): I updated my Java version to 8.0_74. The error is still there :(.
编辑 (2)：我将 Java 版本更新为 8.0_74。错误仍然存在:(。
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00000001073cdef8, pid=11227, tid=19715
#
# JRE version: Java(TM) SE Runtime Environment (8.0_74-b02) (build 1.8.0_74-b02)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# V [libjvm.dylib+0x3cdef8] PhaseIdealLoop::idom_no_update(Node*) const+0x12
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x00007f89e481c800): JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=19715, stack(0x000070000104a000,0x000070000114a000)]
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008
EDIT (3): Core Dump
编辑（3）：核心转储
So finally I created a core dump and loaded it into Java VisualVM (I could not use the solution presented by DROY because calling jmap lead to another error: "Error attaching to core file: Can't attach to the core file"). The threaddump created with VisualVM results in:
所以最后我创建了一个核心转储并将其加载到 Java VisualVM（我无法使用 DROY 提供的解决方案，因为调用 jmap 导致另一个错误：“错误附加到核心文件：无法附加到核心文件”）。使用 VisualVM 创建的线程转储结果：
Thread 30239 "Keep-Alive-Timer": (state = BLOCKED)
at java.lang.Thread.sleep(Native Method)
at sun.net.www.http.KeepAliveCache.run(KeepAliveCache.java:172)
at java.lang.Thread.run(Thread.java:745)
Thread 29699 "threadDeathWatcher-4-1": (state = BLOCKED)
at java.lang.Thread.sleep(Native Method)
at io.netty.util.ThreadDeathWatcher$Watcher.run(ThreadDeathWatcher.java:137)
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
at java.lang.Thread.run(Thread.java:745)
Thread 26635 "nioEventLoopGroup-3-1": (state = IN_NATIVE)
at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:117)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x00000006c049ec98> (a io.netty.channel.nio.SelectedSelectionKeySet)
- locked <0x00000006c049ec88> (a java.util.Collections$UnmodifiableSet)
- locked <0x00000006c049ecb8> (a sun.nio.ch.KQueueSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:622)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:310)
at io.netty.util.concurrent.SingleThreadEventExecutor.run(SingleThreadEventExecutor.java:110)
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)
at java.lang.Thread.run(Thread.java:745)
Thread 29187 "pool-3-thread-1": (state = BLOCKED)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at kafka.consumer.ConsumerIterator.makeNext(ConsumerIterator.scala:63)
at kafka.consumer.ConsumerIterator.makeNext(ConsumerIterator.scala:33)
at kafka.utils.IteratorTemplate.maybeComputeNext(IteratorTemplate.scala:66)
at kafka.utils.IteratorTemplate.hasNext(IteratorTemplate.scala:58)
at com.sosse.common.messaging.DefaultHandler.doRun(DefaultHandler.java:22)
at com.sosse.common.concurrency.DefaultRunnable.run(DefaultRunnable.java:11)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Thread 28675 "pool-4-thread-1": (state = BLOCKED)
at java.lang.Thread.sleep(Native Method)
at io.netty.util.HashedWheelTimer$Worker.waitForNextTick(HashedWheelTimer.java:461)
at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:360)
at java.lang.Thread.run(Thread.java:745)
Thread 28163 "ConsumerFetcherThread-analytics-group_Philipp.local-1458441725398-581eabc3-0-0": (state = IN_NATIVE)
at sun.nio.ch.Net.poll(Native Method)
at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954)
- locked <0x00000006c056d538> (a java.lang.Object)
at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:204)
- locked <0x00000006c056d5b8> (a java.lang.Object)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
- locked <0x00000006c056d5f8> (a sun.nio.ch.SocketAdaptor$SocketInputStream)
at java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:385)
- locked <0x00000006c056d618> (a java.lang.Object)
at kafka.utils.Utils$.read(Utils.scala:380)
at kafka.network.BoundedByteBufferReceive.readFrom(BoundedByteBufferReceive.scala:54)
at kafka.network.Receive$class.readCompletely(Transmission.scala:56)
at kafka.network.BoundedByteBufferReceive.readCompletely(BoundedByteBufferReceive.scala:29)
at kafka.network.BlockingChannel.receive(BlockingChannel.scala:111)
at kafka.consumer.SimpleConsumer.liftedTree1(SimpleConsumer.scala:71)
at kafka.consumer.SimpleConsumer.kafka$consumer$SimpleConsumer$$sendRequest(SimpleConsumer.scala:68)
- locked <0x00000006c056d6e0> (a java.lang.Object)
at kafka.consumer.SimpleConsumer$$anonfun$fetch$$anonfun$apply$mcV$sp.apply$mcV$sp(SimpleConsumer.scala:112)
at kafka.consumer.SimpleConsumer$$anonfun$fetch$$anonfun$apply$mcV$sp.apply(SimpleConsumer.scala:112)
at kafka.consumer.SimpleConsumer$$anonfun$fetch$$anonfun$apply$mcV$sp.apply(SimpleConsumer.scala:112)
at kafka.metrics.KafkaTimer.time(KafkaTimer.scala:33)
at kafka.consumer.SimpleConsumer$$anonfun$fetch.apply$mcV$sp(SimpleConsumer.scala:111)
at kafka.consumer.SimpleConsumer$$anonfun$fetch.apply(SimpleConsumer.scala:111)
at kafka.consumer.SimpleConsumer$$anonfun$fetch.apply(SimpleConsumer.scala:111)
at kafka.metrics.KafkaTimer.time(KafkaTimer.scala:33)
at kafka.consumer.SimpleConsumer.fetch(SimpleConsumer.scala:110)
at kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:94)
at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:86)
at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:60)
Thread 27651 "analytics-group_Philipp.local-1458441725398-581eabc3-leader-finder-thread": (state = BLOCKED)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at kafka.consumer.ConsumerFetcherManager$LeaderFinderThread.doWork(ConsumerFetcherManager.scala:61)
at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:60)
Thread 27139 "analytics-group_Philipp.local-1458441725398-581eabc3_watcher_executor": (state = BLOCKED)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
at kafka.consumer.ZookeeperConsumerConnector$ZKRebalancerListener$$anon.run(ZookeeperConsumerConnector.scala:544)
Thread 26115 "kafka-consumer-scheduler-0": (state = BLOCKED)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Thread 25603 "main-EventThread": (state = BLOCKED)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:494)
Thread 25091 "main-SendThread(localhost:2181)": (state = IN_NATIVE)
at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:117)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x00000006c0022c50> (a sun.nio.ch.Util)
- locked <0x00000006c0022c60> (a java.util.Collections$UnmodifiableSet)
- locked <0x00000006c0022c00> (a sun.nio.ch.KQueueSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:349)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
Thread 24579 "ZkClient-EventThread-16-localhost:2181": (state = BLOCKED)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.I0Itec.zkclient.ZkEventThread.run(ZkEventThread.java:67)
Thread 24067 "metrics-meter-tick-thread-2": (state = BLOCKED)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Thread 23555 "metrics-meter-tick-thread-1": (state = BLOCKED)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Thread 23303 "pool-1-thread-1": (state = BLOCKED)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
VM Thread 20995 "Service Thread": (state = BLOCKED)
VM Thread 20483 "C1 CompilerThread3": (state = BLOCKED)
VM Thread 19971 "C2 CompilerThread2": (state = IN_NATIVE)
VM Thread 19459 "C2 CompilerThread1": (state = IN_NATIVE)
VM Thread 18947 "C2 CompilerThread0": (state = IN_NATIVE)
Thread 15887 "Signal Dispatcher": (state = BLOCKED)
Thread 14339 "Finalizer": (state = BLOCKED)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000006c005fa88> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
- locked <0x00000006c005fa88> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
Thread 13827 "Reference Handler": (state = BLOCKED)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000006c0029358> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x00000006c0029358> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
Thread 2823 "main": (state = BLOCKED)
at java.lang.Thread.sleep(Native Method)
at com.sosse.analytics.ActivityProducer.sleep(ActivityProducer.java:110)
at com.sosse.analytics.DemoMain.startApplication(DemoMain.java:37)
at com.sosse.common.application.DefaultApplication.start(DefaultApplication.java:166)
- locked <0x00000006c00e6080> (a java.lang.Thread)
at com.sosse.common.application.DefaultApplication.start(DefaultApplication.java:118)
at com.sosse.analytics.DemoMain.main(DemoMain.java:48)
EDIT (4): Source Code Deserializer
编辑（4）：源代码解串器
public static Object[] deserialize(final JsonElement jsonElement, final JsonDeserializationContext context, final BiFunction<Class<?>, JsonElement, Serializable[]> timeSeriesDeserializer) {
final JsonObject jsonObject = jsonElement.getAsJsonObject();
// get the important classes
final Class<?> bucketContent = resolveClass("bucketContent", jsonObject, context);
// configuration
final TimeUnit timeUnit = context.deserialize(jsonObject.get("timeUnit"), TimeUnit.class);
final int bucketSize = context.deserialize(jsonObject.get("bucketSize"), int.class);
final boolean fillNumberWithZero = context.deserialize(jsonObject.get("fillNumberWithZero"), boolean.class);
// the values
final Long now = context.deserialize(jsonObject.get("now"), Long.class);
final Serializable[] timeSeries = timeSeriesDeserializer.apply(bucketContent, jsonObject.get("timeSeries"));
@SuppressWarnings("unchecked")
final BucketTimeSeriesConfig config = new BucketTimeSeriesConfig(bucketContent, timeUnit, timeSeries.length, bucketSize, fillNumberWithZero);
return new Object[]{config, timeSeries, now};
}
回答by apangin
The crash report tells the error has happened in JIT compiler thread:
崩溃报告告诉 JIT 编译器线程中发生了错误：
Current thread (0x00007f89e481c800): JavaThread "C2 CompilerThread1"
Take the following steps do diagnose compiler problems:
采取以下步骤来诊断编译器问题：
Try the most recent JVM build available in JDK 9 EA: https://jdk9.java.net/download/
If the problem disappears, you can either stay with this version or try to locate the exact commit that solves the issue and then backport it to JDK 8. How to backport fixes and how to build HotSpot yourself - it's a separate topic, but I can tell if you're interested.
If the problem persists, try to find a problematic method and exclude it from compilation.
Current CompileTask: C2: 114667 5303 4 com.sosse.time.timeseries.gson.TypeConverterHelper::deserialize (157 bytes)Looks like in your case it fails compiling
TypeConverterHelper.deserialize(). Add the following JVM option to exclude this particular method:-XX:CompileCommand=exclude,com.sosse.time.timeseries.gson.TypeConverterHelper::deserializeIf it does not help, try to exclude more methods by providing multiple
-XX:CompileCommand. To find candidates to exclude use-XX:+PrintCompilationand look at the bottom of the printed list. You can also exclude the whole classes and packages from compilation, e.g.-XX:CompileCommand=exclude,com.sosse.time.timeseries.gson.*::*Try to disable certain compiler optimizations one by one. Some options to try are:
-XX:-DoEscapeAnalysis -XX:LoopUnrollLimit=0 -XX:-PartialPeelLoop -XX:-UseLoopPredicate -XX:-LoopUnswitching -XX:-ReassociateInvariants -XX:MaxInlineLevel=1 -XX:-IncrementalInline -XX:-RangeCheckElimination -XX:-EliminateAllocations -XX:-UseTypeProfile -XX:AliasLevel=0Whether the problematic method/optimization is found or not, run JVM again with
-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilationThis will create
hotspot_pid1234.logfile in the current directory with detailed compilation log.Submit the bug report at bugreport.java.com. Select
Product/Category: HotSpot Virtual Machine (errors) Subcategory: J2SE Server CompilerMake sure to include full
hs_err_pid.logandhotspot_pid.logfrom step 5. It would be very helpful if you could provide a reduced self-contained example that demonstrates the problem.For a faster reaction you may also post a message to hotspot-compiler-devmailing list.
尝试 JDK 9 EA 中可用的最新 JVM 构建：https: //jdk9.java.net/download/
如果问题消失，您可以继续使用此版本，也可以尝试找到解决问题的确切提交，然后将其向后移植到 JDK 8。如何向后移植修复程序以及如何自己构建 HotSpot - 这是一个单独的主题，但我可以告诉你是否有兴趣。
如果问题仍然存在，请尝试查找有问题的方法并将其从编译中排除。
Current CompileTask: C2: 114667 5303 4 com.sosse.time.timeseries.gson.TypeConverterHelper::deserialize (157 bytes)看起来在您的情况下它无法编译
TypeConverterHelper.deserialize()。添加以下 JVM 选项以排除此特定方法：-XX:CompileCommand=exclude,com.sosse.time.timeseries.gson.TypeConverterHelper::deserialize如果没有帮助，请尝试通过提供多个
-XX:CompileCommand. 要查找排除使用的候选人-XX:+PrintCompilation，请查看打印列表的底部。您还可以从编译中排除整个类和包，例如-XX:CompileCommand=exclude,com.sosse.time.timeseries.gson.*::*尝试一一禁用某些编译器优化。可以尝试的一些选项是：
-XX:-DoEscapeAnalysis -XX:LoopUnrollLimit=0 -XX:-PartialPeelLoop -XX:-UseLoopPredicate -XX:-LoopUnswitching -XX:-ReassociateInvariants -XX:MaxInlineLevel=1 -XX:-IncrementalInline -XX:-RangeCheckElimination -XX:-EliminateAllocations -XX:-UseTypeProfile -XX:AliasLevel=0无论是否找到有问题的方法/优化，再次运行JVM
-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation这将
hotspot_pid1234.log在当前目录中创建带有详细编译日志的文件。在bugreport.java.com提交错误报告。选择
Product/Category: HotSpot Virtual Machine (errors) Subcategory: J2SE Server Compiler确保包含第 5 步中的full
hs_err_pid.log和hotspot_pid.logfrom 。如果您能提供一个简化的独立示例来演示该问题，将会非常有帮助。为了更快地做出反应，您还可以向hotspot-compiler-dev邮件列表发布一条消息。
回答by Stephen C
It looks like JDK bug JDK-6675699. According to the bug report, the fix for that bug has been backported to 8u74, 8u81 and 8u82.
它看起来像 JDK 错误JDK-6675699。根据错误报告，该错误的修复程序已向后移植到 8u74、8u81 和 8u82。
Note that (as of right now) the end-user focused Java Download Siteoffers 8u73 as the latest version. You can get 8u74 from the Java Developer Download Site.
请注意（截至目前）面向最终用户的Java 下载站点提供 8u73 作为最新版本。您可以从Java 开发人员下载站点获得 8u74 。
If updating to 8u74 doesn't solve the problem, then you should submit this to Oracle as a bug report. The likely diagnosis is that you are running code that is causing the JIT code compiler to crash when it attempt to compile / optimize it. That's what PhaseIdealLoop::idom_no_updateis indicating.
如果更新到 8u74 不能解决问题，那么您应该将此作为错误报告提交给 Oracle。可能的诊断是您正在运行的代码导致 JIT 代码编译器在尝试编译/优化它时崩溃。这PhaseIdealLoop::idom_no_update就是表明。
JDK-6675699 is for a specific JIT compiler bug. There could well be other JIT compiler bugs that have not been diagnosed. If you submit a new bug report, it could help the maintainers to track down those bugs. However, a bug report will only be useful to them if you can provide enough information to allow them to reproduce your bug.
JDK-6675699 针对特定的 JIT 编译器错误。很可能还有其他尚未诊断的 JIT 编译器错误。如果您提交新的错误报告，它可以帮助维护人员追踪这些错误。但是，只有在您提供足够的信息以允许他们重现您的错误时，错误报告才会对他们有用。
(Of course, it is also possible that the root cause is something completely different; e.g. something in your code 3rd party code that is corrupting JVM data structures that is causing the compiler to crash. But it would a huge coincidence for the corruptions to repeatably break the compiler ... and only the compiler.)
（当然，也有可能根本原因完全不同；例如，您的代码中的某些 3rd 方代码会破坏 JVM 数据结构，从而导致编译器崩溃。但如果重复出现这些破坏，那将是一个巨大的巧合破坏编译器……而且只有编译器。）
UPDATE- According to these Release Notes, the version you actually need is Java SE 8u74-b32.
更新- 根据这些发行说明，您实际需要的版本是 Java SE 8u74-b32。
回答by The Roy
I think you should spend some time in analyzing the core.
我认为你应该花一些时间来分析核心。
Segmentation fault
分段故障
There are several possible reasons for this. There could be a bug in the JVM itself, or in a package (some of these are written in C or C++). It could also be due to a misconfiguration where incompatible components are used together.
这有几个可能的原因。JVM 本身或包中可能存在错误（其中一些是用 C 或 C++ 编写的）。也可能是由于配置错误，将不兼容的组件一起使用。
From experience, a JVM bug is the least likely of these. Although @Stephen thinks that is the likely case here.
根据经验，JVM 错误的可能性最小。尽管@Stephen 认为这是可能的情况。
If you capture the stack trace at the point of the crash, this might give you some clues as to where exactly the crash is occurring.
如果您在崩溃点捕获堆栈跟踪，这可能会为您提供有关崩溃确切发生位置的一些线索。
Firstly, I see that you need to confgure ulimit -c unlimited so that you can store the core file to disk.
首先，我看到您需要配置 ulimit -c unlimited 以便您可以将核心文件存储到磁盘。
Analyze Core file
Once you do that, you should analyze the core using the following method.
分析核心文件
执行此操作后，您应该使用以下方法分析核心。
To convert the file use the commandline tool jmap.
要转换文件，请使用命令行工具 jmap。
jmap -dump:format=b,file=dump.hprof /usr/bin/java core_file
where:
在哪里：
dump.hprof is the name of the hprof file you wish to create
dump.hprof 是您要创建的 hprof 文件的名称
/usr/bin/java is the path to the version of the java binary that generated the core dump
/usr/bin/java 是生成核心转储的 java 二进制文件版本的路径
