java 服务异常崩溃 JVM报错：Failed to write core dump. Core dumps have been disabled.
bigDataShare
于 2020-06-23 13:59:19 发布
10492
收藏 11
分类专栏： 03-jvm
版权
华为开发者联盟鸿蒙专区
文章已被社区收录
加入社区
03-jvm
专栏收录该内容
1 篇文章0 订阅
订阅专栏
目录
1 问题点
2 分析问题
3 解决问题
Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
1 问题点
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f9577264930, pid=1415, tid=0x00007f957511b700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_181-b13) (build 1.8.0_181-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.181-b13 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libjson.so+0x11930] Json::Value::swap(Json::Value&)+0x0
#
# 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
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- T H R E A D ---------------
Current thread (0x00007f9568068800): JavaThread "nioEventLoopGroup-3-3" [_thread_in_native, id=1448, stack(0x00007f957501b000,0x00007f957511c000)]
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008
Registers:
RAX=0x00007f956400f520, RBX=0x0000000000000000, RCX=0x0000000000000000, RDX=0x0000000000003074
RSP=0x00007f9575118df8, RBP=0x00007f9558419780, RSI=0x00007f9575118e00, RDI=0x0000000000000000
R8 =0x0000000000000000, R9 =0x0000000000000003, R10=0x0000000000000002, R11=0x00007f95dcdfb6d0
R12=0x00007f9575118e60, R13=0x00007f9599ad63e0, R14=0x0000000000000000, R15=0x00007f9575118f60
RIP=0x00007f9577264930, EFLAGS=0x0000000000010202, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x00007f9575118df8)
0x00007f9575118fb8: 00007f9564017070 00007f9558410eb0
0x00007f9575118fc8: 00007f95772611f4 00007f9558419708
0x00007f9575118fd8: 00007f95582f5134 00007f95584196e0
0x00007f9575118fe8: 00007f9577484540 fffffffffffffff0
Instructions: (pc=0x00007f9577264930)
0x00007f9577264910: 48 8b 17 48 8b 06 48 89 07 8b 46 08 48 89 16 8b
0x00007f9577264920: 57 08 89 47 08 89 56 08 c3 90 66 0f 1f 44 00 00
0x00007f9577264930: 0f b6 57 08 0f b6 46 08 88 47 08 88 56 08 48 8b
0x00007f9577264940: 06 48 8b 17 48 89 07 48 89 16 0f b6 57 09 0f b6
Register to memory mapping:
RAX=0x00007f956400f520 is an unknown value
RBX=0x0000000000000000 is an unknown value
RCX=0x0000000000000000 is an unknown value
RDX=0x0000000000003074 is an unknown value
RSP=0x00007f9575118df8 is pointing into the stack for thread: 0x00007f9568068800
RBP=0x00007f9558419780 is an unknown value
RSI=0x00007f9575118e00 is pointing into the stack for thread: 0x00007f9568068800
RDI=0x0000000000000000 is an unknown value
R8 =0x0000000000000000 is an unknown value
R9 =0x0000000000000003 is an unknown value
R10=0x0000000000000002 is an unknown value
R11=0x00007f95dcdfb6d0: <offset 0x1846d0> in /lib64/libc.so.6 at 0x00007f95dcc77000
R12=0x00007f9575118e60 is pointing into the stack for thread: 0x00007f9568068800
R13=0x00007f9599ad63e0: _ZNSs4_Rep20_S_empty_rep_storageE+0 in /lib64/libstdc++.so.6 at 0x00007f95997cf000
R14=0x0000000000000000 is an unknown value
R15=0x00007f9575118f60 is pointing into the stack for thread: 0x00007f9568068800
Stack: [0x00007f957501b000,0x00007f957511c000], sp=0x00007f9575118df8, free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libjson.so+0x11930] Json::Value::swap(Json::Value&)+0x0
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 1453 com.macli.maCliApi.maCli_GetValueN(J[I[B)I (0 bytes) @ 0x00007f95c54d7620 [0x00007f95c54d75c0+0x60]
j com.zt.ecftradetob.business.B61003.maCliFun_10303003(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;ILjava/lang/String;Lcom/zt/ecftradetob/dao/OrderListInfo;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Lcom/alibaba/fastjson/JSONObject;+731
j com.zt.ecftradetob.business.B61003.execute(Lcom/zt/ecftradetob/dto/R61003;)Lcom/cisc/service/api/Response;+218
j sun.reflect.GeneratedMethodAccessor53.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+40
J 2005 C1 sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; (10 bytes) @ 0x00007f95c51c9a44 [0x00007f95c51c9940+0x104]
J 2004 C1 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; (62 bytes) @ 0x00007f95c543874c [0x00007f95c5438360+0x3ec]
j com.zt.handler.StockWebSocketServerHandler.mapping(Ljava/util/HashMap;Lio/netty/channel/Channel;)V+397
J 2139 C2 io.netty.channel.SimpleChannelInboundHandler.channelRead(Lio/netty/channel/ChannelHandlerContext;Ljava/lang/Object;)V (74 bytes) @ 0x00007f95c565a134 [0x00007f95c5658f00+0x1234]
J 2078 C2 io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(Ljava/lang/Object;)Lio/netty/channel/ChannelHandlerContext; (12 bytes) @ 0x00007f95c53525ac [0x00007f95c53523e0+0x1cc]
J 2457 C1 io.netty.handler.codec.ByteToMessageDecoder.channelRead(Lio/netty/channel/ChannelHandlerContext;Ljava/lang/Object;)V (311 bytes) @ 0x00007f95c5674b24 [0x00007f95c56731a0+0x1984]
J 2150 C2 io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(Lio/netty/channel/ChannelHandlerContext;Ljava/lang/Object;)V (9 bytes) @ 0x00007f95c536fd84 [0x00007f95c536fba0+0x1e4]
J 2041 C2 io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Lio/netty/channel/AbstractChannelHandlerContext;Ljava/lang/Object;)V (53 bytes) @ 0x00007f95c526a6d0 [0x00007f95c526a560+0x170]
J 2249 C1 io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read()V (298 bytes) @ 0x00007f95c557fd34 [0x00007f95c557e6e0+0x1654]
J 2077 C2 io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized()V (99 bytes) @ 0x00007f95c5147b88 [0x00007f95c51479a0+0x1e8]
J 2204% C1 io.netty.channel.nio.NioEventLoop.run()V (236 bytes) @ 0x00007f95c552e2fc [0x00007f95c552d760+0xb9c]
j io.netty.util.concurrent.SingleThreadEventExecutor$5.run()V+44
j io.netty.util.internal.ThreadExecutorMap$2.run()V+11
j io.netty.util.concurrent.FastThreadLocalRunnable.run()V+4
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
2 分析问题
上面重要一句话是
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
告诉我们用这个命令解决问题 ulimit -c unlimited
3 解决问题
[root@server01 logs]# ulimit -c unlimited
[root@server01 logs]# ulimit -c -l
core file size (blocks, -c) unlimited
max locked memory (kbytes, -l) 64
[root@server01 logs]#
这里备注一下：该方法并未解决问题，希望这里不要对其他网友产生误解。
暂时解决方式
说linux的句柄太少,就是java程序进程,线程不能打开太多文件,等原因
查看句柄大小,临时性设置句柄为65536
[root@server01 ecftob]$ ulimit -n
1024
[root@server01 ecftob]# ulimit -HSn 65536
其他解决方式参考网上博客
下面一篇博文提供了解决思路
https://www.cnblogs.com/songyuejie/p/11221381.html
默认情况下Linux服务起的core core file size设置为0，需要调整该参数，但是这个参数并不能 解决问题；
问题的根本原因在于服务器的运行应用程序的打开文件的最大数及最大进程数设置的相对较小默认为4096
需要修改如下配置：
/etc/security/limits.conf
————————————————
版权声明：本文为CSDN博主「bigDataShare」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/sdrfengmi/article/details/106918337