# A fatal error has been detected by the Java Runtime Environment:
# SIGBUS (0x7) at pc=0x00007f1ae404fd50, pid=23224, tid=139753370498816
# JRE version: 7.0_17-b02
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# v ~StubRoutines::jbyte_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.sun.com/bugreport/crash.jsp
JVM致命错误日志（hs_err_pid.log）。
为了core dumping,执行命令ulimit -c unlimited。
参考博客园上的一篇文章
http://www.cnblogs.com/qq78292959/archive/2012/05/08/2490443.html
手动触发core：kill -6 pid(-6可以产生，默认的文件名是core.pid)。
core文件很大，有200多Mb。
分析对比最近3个月的“hs_err_pid23224.log”文件：
Problematic frame:
# v ~StubRoutines::jbyte_disjoint_arraycopy
# Problematic frame:
# v ~StubRoutines::jint_disjoint_arraycopy
# Problematic frame:
# C [libc.so.6+0x89f74] __tls_get_addr@@GLIBC_2.3+0x89f74
# Problematic frame:
# C [libc.so.6+0x89eb0] __tls_get_addr@@GLIBC_2.3+0x89eb0
# Problematic frame:
# v ~StubRoutines::jbyte_disjoint_arraycopy
# Problematic frame:
# C [libc.so.6+0x89f74] __tls_get_addr@@GLIBC_2.3+0x89f74
# Problematic frame:
# V [libjvm.so+0x66e040] _Copy_arrayof_conjoint_jlongs+0x30
# Problematic frame:
# C [libc.so.6+0x89e68] __tls_get_addr@@GLIBC_2.3+0x89e68
# Problematic frame:
# v ~StubRoutines::jbyte_disjoint_arraycopy
# Problematic frame:
# v ~StubRoutines::jbyte_disjoint_arraycopy
# Problematic frame:
# v ~StubRoutines::jbyte_disjoint_arraycopy
不清楚，是不是内存不足导致的，手动设置了Tomcat的JVM内存参数。
JAVA_OPTS="$JAVA_OPTS -Xms256m -Xmx1024m -XX:PermSize=128M -XX:MaxPermSize=256m"
现在只能等待下一次crash，看看core文件。
鉴于Tomcat服务器现状，有必要监控内存情况，目前想到的3种方法：
1.jconsole监控远程JVM，需要配置。
2.web.xml配置Filter，监听内存情况。
3.Tomcat自带的manager项目，可以留着，说不定用得上。
下午又crash了一次，没有产生core文件，“ulimit ”命令没有生效。
向阿里云提交了工单，看看专家能不能给点意见。
## A fatal error has been detected by the Java Runtime Environment:## SIGBUS (0x7) at pc=0x00007f1ae404fd50, pid=23224, tid=139753370498816## JRE version: 7.0_17-b02# Java VM: Java HotSpot(TM) 64-Bit
hs
_
err
_
pid
简介
hs
_
err
_
pid
<
pid
>.
log
是java程序发生core的时候产生的
文件
，里面有当时出错时
jvm
的执行情况。
头
文件
解读可以查看问题
头
文件
包含了简单的信息阐述，里面就core掉的
原因
# An unexpected
err
or ha...
# A fatal
err
or has been detected by the Java Runtime Environment:
# SIGBUS (0x7) at pc=0x00007f9a785c2690,
pid
=1150, tid=140300276668160
# JRE version: 6.0_31-b04
# Java VM: Java HotSpot(TM) 6...
内存映射
文件
是一个很好的并且经常被忽视的工具。 我不会在这里详细介绍它们的工作方式（使用 力 Google Luke！），但我将快速总结其优势：
操作系统提供的延迟加载和写入缓存（您不必自己编写，并且可以确信操作系统的性能良好）
易于读取复杂的二进制数据（例如其中编码有各种相对偏移量的二进制数据）
可用作高性能IPC机制
即使您的进程崩溃（即使操作系统仍然存在）也可以写...
when we are accessing some io resources,like writing to disk,there may be a java
jvm
crash by below:
# A fatal
err
or has been detected by the Java Runtime Environment:
# SIGBUS (0x7) a...
这个错误一般是由于
Log
stash 的启动脚本中的一个参数解析器（
jvm
_options_parser）出现问题而引起的。
具体
来说，可能是由于
Log
stash 的启动脚本没有正确设置 CLASSPATH 环境变量，或者是由于
Log
stash 的启动脚本中缺少了必要的类库。
解决这个问题的方法如下：
1.检查
Log
stash 的启动脚本是否正确设置了 CLASSPATH 环境变量。可以通过在命令行中运行 "echo $CLASSPATH" 来检查环境变量是否正确设置。
2.确保
Log
stash 的启动脚本中包含了所有必要的类库。可以尝试重新下载
Log
stash 并重新安装，或者手动添加缺少的类库。
3.检查
Log
stash 的
日志
文件
以获取更多信息。
日志
文件
中可能包含有关错误
原因
的更多详细信息，可以帮助您更好地诊断问题。
4.尝试升级
Log
stash 的版本。有时，新版本的
Log
stash 可能已经修复了这个问题。
Statement not bound, 使用MybatisPlus时的SqlSessionFactory和MybatisSqlSessionFactoryBean的问题
兴奋的大母鸡:
从迷之自信到逻辑自信（简版）
检验电子邮件地址是否真实存在
kkkspringkkk:
小米开源便签Notes-源码研究(0)-整体功能介绍(图文并茂)
liksim:
