jlong_disjoint_arraycopy ulimi

一、应用服务器日志

# 应用服务器日志如下：


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0x7) at pc=0x00007f41f90527b0, pid=65323, tid=139915581314816
#
# 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 linux-amd64 compressed oops)
# Problematic frame:
# v  ~StubRoutines::jlong_disjoint_arraycopy
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /usr/local/tomcat9_80/bin/hs_err_pid65323.log

二、hs_err_pid65323.log 日志

# /usr/local/tomcat9_80/bin/hs_err_pid65323.log 日志如下：


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0x7) at pc=0x00007f41f90527b0, pid=65323, tid=139915581314816
#
# 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 linux-amd64 compressed oops)
# Problematic frame:
# v  ~StubRoutines::jlong_disjoint_arraycopy
#
# 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 (0x00007f406c00b000):  JavaThread "SimpleAsyncTaskExecutor-475" [_thread_in_Java, id=87147, stack(0x00007f40a275d000,0x00007f40a285e000)]

siginfo: si_signo: 7 (SIGBUS), si_code: 2 (BUS_ADRERR), si_addr: 0x00007f40a2f9a000

Registers:
RAX=0x00007f40a2f9aa30, RBX=0x000000072ae79068, RCX=0x000000072b2ab120, RDX=0xfffffffffffffec1
RSP=0x00007f40a285b3c0, RBP=0x00007f40a285b3c0, RSI=0x000000072b2aa370, RDI=0x00007f40a2f9aa28
R8 =0x0000000000000db8, R9 =0x0000000000000db8, R10=0x00007f41f9052da0, R11=0x000000072b2aa360
R12=0x0000000000000000, R13=0x0000000000000db8, R14=0x0000000000001c78, R15=0x00007f406c00b000
RIP=0x00007f41f90527b0, EFLAGS=0x0000000000010292, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007f40a285b3c0)
0x00007f40a285b3c0:   000000072b2aa330 00007f41fbdeaef2
0x00007f40a285b3d0:   000000072af8a1a8 00007f41fad20225
0x00007f40a285b3e0:   000000072af88148 000000072af7d408
0x00007f40a285b3f0:   0000000000000000 00007f41fa7901d8
0x00007f40a285b400:   00000005cf4df180 000000072af8a190
0x00007f40a285b410:   000000072af7d788 00007f41fad20225
0x00007f40a285b420:   000000072b2aa330 00007f41fbbf41b8
0x00007f40a285b430:   00000000e55efb16 00007f41fb23cf3c
0x00007f40a285b440:   0000000700000007 000000072b2aa330
0x00007f40a285b450:   000000072af8a1a8 00007f41fad20225
0x00007f40a285b460:   000000072af88148 0000000700000db8
0x00007f40a285b470:   0000000700000000 000000072b2aa360
0x00007f40a285b480:   000000072af7daa8 000000072af7d700
0x00007f40a285b490:   00000005cfaa3770 0000000300000000
0x00007f40a285b4a0:   0000000000000002 0000000500000004
0x00007f40a285b4b0:   00000007c0003000 00007f41faa7f4fc
0x00007f40a285b4c0:   000000072af7e968 00007f41e55cf165
0x00007f40a285b4d0:   0000000000000db8 000000072af88148
0x00007f40a285b4e0:   000000072af8a190 000000072b2aa330
0x00007f40a285b4f0:   0000000700000db8 000000072b2aa360
0x00007f40a285b500:   000000072af7e968 000000072b2aa288
0x00007f40a285b510:   b9b6c56ce5655451 00000007c010d718
0x00007f40a285b520:   00000005cf81f3e0 00000005cdb62b60
0x00007f40a285b530:   000000072af8d018 000000072b2aa200
0x00007f40a285b540:   000000072b2aa268 00007f41fc032f14
0x00007f40a285b550:   000000072af8a190 0000000700000001
0x00007f40a285b560:   000000072b2aa268 000000072b2aa268
0x00007f40a285b570:   000000072af8cfd8 00000001e55f1432
0x00007f40a285b580:   000000072af8a1a8 0000001000000008
0x00007f40a285b590:   0000000000000001 00007f4100000000
0x00007f40a285b5a0:   0000000300000002 0000000500000006
0x00007f40a285b5b0:   0000000000000001 0000000700000004 

Instructions: (pc=0x00007f41f90527b0)
0x00007f41f9052790:   da e9 32 00 00 00 48 8b 44 d7 08 48 89 44 d1 08
0x00007f41f90527a0:   48 ff c2 75 f1 48 33 c0 c9 c3 66 0f 1f 44 00 00
0x00007f41f90527b0:   c5 fe 6f 44 d7 c8 c5 fe 7f 44 d1 c8 c5 fe 6f 4c
0x00007f41f90527c0:   d7 e8 c5 fe 7f 4c d1 e8 48 83 c2 08 7e e2 48 83 

Register to memory mapping:

RAX=0x00007f40a2f9aa30 is an unknown value
RBX=0x000000072ae79068 is an oop
java.nio.DirectByteBufferR 
 - klass: 'java/nio/DirectByteBufferR'
RCX=0x000000072b2ab120 is an oop

三、问题分析

#根据上面的日志，大概猜测报错的位置可能涉及：

# jlong_disjoint_arraycopy 可能是数组拷贝的时候，toArray();
# SimpleAsyncTaskExecutor 可能是异步方法，并且没有指定线程池，使用了默认的线程池，有可能使用了@Async
# DirectByteBuffer 可能是直接内存；

# core dump就是在进程crash时，把包括内存在内的现场保留下来，以备故障分析；
# 既然 Failed to write core dump ，那么就先配置它吧，期望再崩溃的时候，有个记录；

# 根据业务日志最后的打印，和以上的三个猜测，我这里基本定位到了@Async的一个方法；

四、问题处理

# 一、查看是否开启core文件的生成
# ulimit -c 的输出为0，代表是关闭状态
root@azserv:~# ulimit -c
0

# 二、把core文件的大小设置为无限大
root@azserv:~# ulimit -c unlimited

# 查看
root@azserv:~# ulimit -c
unlimited

# 查看
root@azserv:~# ulimit -c -l
core file size          (blocks, -c) unlimited
max locked memory       (kbytes, -l) 64

#三、修改limits.conf文件
# 默认情况下Linux服务起的core core file size设置为0，需要调整该参数，
# 但是这个参数并不能 解决问题；

# 问题的根本原因在于，服务器的运行应用程序打开文件的最大数及最大进程数，设置的相对较小，
# 默认为4096;


root@azserv:~# vi /etc/security/limits.conf

# *这个通配符不一定能够被识别为所有用户，建议使用用户名

* soft nofile 655350 #任何用户可以打开的最大的文件描述符数量，默认1024，这里的数值会限制tcp连接
* hard nofile 655350
* soft nproc 655350  #任何用户可以打开的最大进程数
* hard nproc 655350

root soft nofile 655350
root hard nofile 655350
root soft nproc 655350
root hard nproc 655350

五、验证配置文件生效

# 不要在其他文件写死了ulimit,比如:ulimit -n 65535,否则怎么修改都没用

root@azserv:~# cat /etc/ssh/sshd_config
UsePAM yes  # 这个保证其他的用户也能修改设置

root@azserv:~# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 127643
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 655350
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 655350
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

# 我这里都已经生效，注意，不需要重启，但需要重新登录；
# open files                      (-n) 655350
# max user processes              (-u) 655350

*****************************************************

************************END***********************

*****************************************************

关于limit 值

# 设置nofile的hard limit还有一点要注意的就是hard limit不能大于/proc/sys/fs/nr_open，
# 假如hard limit大于nr_open，注销后将无法正常登录。

root@azserv:~# cat /proc/sys/fs/nr_open
1048576

-bash-4.2# cat /proc/sys/fs/file-nr
4928    0       1610348

4928 表示：系统已分配使用的打开文件描述符数
0： 第二个数为分配后已释放的（目前已不再使用）
1610348： 等于file-max

关于 ulimit 命令

对于每个用户，系统限制其最大进程数，为提高性能，可以根据设备资源情况，
设置个Linux用户的最大进程数，一些需要设置为无限制：

数据段长度：ulimit -d unlimited
最大内存大小：ulimit -m unlimited
堆栈大小：ulimit -s unlimited

我们在用这个命令的时候主要是为了产生core文件，就是程序运行发行段错误时的文件。

当系统中的一些程序在遇到一些错误以及crash时，系统会自动产生core文件记录crash时刻系统信息，
包括内存和寄存器信息，用以程序员日后debug时可以使用。
这些错误包括段错误、非法指令、总线错误或用户自己生成的退出信息等等，
一般地，core文件在当前文件夹中存放。

core文件有时可能在你发生错误时，并没有出现在你当前的文件夹中，
发生这种情况的原因有两个：
一个是当前终端被设置为不能弹出core文件；
另一种则是core文件被指定了路径。

对于前者，我们可以使用ulimit命令对core文件的大小进行设定。
一般默认情况下，core文件的大小被设置为0，这样系统就不dump出core文件了。
这时，使用命令：ulimit -c unlimited进行设置，就可以把core文件的大小设置为无限大，
同时也可以使用数字来替代unlimited，对core文件的上限制做更精确的设定。

开启或关闭core文件的生成
ulimit -c 可以查看是否打开此选项，若为0则为关闭；
ulimit -c 0可手动关闭
ulimit -c 1000 为设置core文件大小最大为1000k

ulimit -c unlimited 设置core文件大小为不限制大小

很多系统在默认的情况下是关闭生成core文件的，这个命令可以加到你的profile中去。

ulimit -a 用来显示当前的各种用户进程限制

root@azserv:~# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 127643
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 127643
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

参考：

https://blog.csdn.net/phmatthaus/article/details/107182265
https://blog.csdn.net/frothmoon/article/details/122210160
https://www.404bugs.com/details/1079152244862799872
https://www.cnblogs.com/songyuejie/p/11221381.html
https://blog.csdn.net/chengyuqiang/article/details/101192730
https://www.cnblogs.com/hoge66/p/14589118.html
https://www.cnblogs.com/kelelipeng/p/16571874.html

https://www.jianshu.com/p/5862e8c69ee6