前言
笔者先前遇到多个SIGBUS crash问题,在此处归纳整理下问题定位思路并且给出复现的用例,以便提升定位同类问题的效率。通常访问内存触发 SIGBUS 有如下几种场景:
(1)未对齐内存的读写
(2)机器物理内存故障
(3)文件映射异常访问
本文主要从 机器物理内存故障 和 文件映射异常访问 两个场景分别阐述问题发生的现象、排查方法以及复现的用例。
机器物理内存故障触发的SIGBUS
机器上很多进程都会出现crash,每次出现crash的堆栈不一样,并且有些进程crash在系统库上,例如 libc.so、libpthread.so。
1. 排查方法
(1)分析 hs_err_pid 文件
从hs_err_pid文件中可以看出访问地址 0x000000054c0bc000 触发 SIGBUS,并且 si_code 为 4 (BUS_MCEERR_AR)。
从官方 sigaction 用户手册中[1]查看到 si_code 中 BUS_MCEERR_AR (4) 、BUS_MCEERR_AO (5) 表示物理内存故障。
BUS_ADRALN
Invalid address alignment.
BUS_ADRERR
Nonexistent physical address.
BUS_OBJERR
Object-specific hardware error.
BUS_MCEERR_AR (since Linux 2.6.32)
Hardware memory error consumed on a machine check;
action required.
BUS_MCEERR_AO (since Linux 2.6.32)
Hardware memory error detected in process but not
consumed; action optional.
(2)分析系统日志
查看出现crash前后时间点的系统日志,可以看到打印出很多 kernel 异常信息(Hardware Error ,hardware memory error等),从系统日志中进一步佐证是由于物理内存故障导致访问内存crash。
文件映射异常访问触发的SIGBUS
文件映射访问异常触发 SIGBUS 在用户态最为常见[2],也最容易触发。通常来说根本原因都是进程 mmap 了一个文件后,另外的进程把这个文件截断了,导致 mmap 出来的某些内存页超出文件的实际大小,访问那些超出的内存页就会触发 SIGBUS。具体来说有以下几种场景:
(1)进程 mmap 一个文件后,其它进程 truncate 该文件到更小;
(2)动态库更新,直接 cp 覆盖;
(3)可执行文件更新,直接 cp 覆盖。
1. 排查方法
我们可以按照如下步骤排查文件映射异常访问触发的SIGBUS:
(1)查看 hs_err_pid 文件 T H R E A D 信息中打印的 si_addr;
(2)查看 hs_err_pid 文件 Dynamic libraries 找到 si_addr 映射的文件;
(3)在业务日志中打印对应文件的操作记录,查看是否存在并发读写问题。
2. 复现案例
在Java应用中,每次文件映射异常访问触发的SIGBUS的线程堆栈可能不一样,下面笔者在下文中阐述下最常见的两个案例。
案例一:并发处理同一文件触发SIGBUS
笔者在业务中多次碰到在x86_64机器中调用 ~StubRoutines::jlong_disjoint_arrayc