记录一次进程重启排查过程

问题现象

遇到一个问题，系统有一个进程半夜重启，但是没有发现core文件，只在日志内看到以下信息。

[814931.140133] xxxx[4601]: segfault at 7fb8a77fea18 ip 0000003689207ef0 sp 00007fffaef50ca0 error 4 in libpthread.so.0[3689200000+17000]

排查步骤

内核代码 , arch/x86/include/asm/traps.h
 * Page fault error code bits:
 *
 *   bit 0 ==     0: no page found    1: protection fault
 *   bit 1 ==     0: read access        1: write access
 *   bit 2 ==     0: kernel-mode access    1: user-mode access
 *   bit 3 ==                1: use of reserved bit detected
 *   bit 4 ==                1: fault was an instruction fetch
 *   bit 5 ==                1: protection keys block access

通过以上信息排查，得知 error 4 是用户层无效内存访问导致，同时能够知道这个问题异常出现在libpthread.so里面。线程库版本为libpthread-2.12.so
通过以上日志的分析，得知libpthread.so的基地址为3689200000，出问题的地址为3689207ef0，相对地址3689207ef0 - 3689200000 = 7ef0
调用objdump -Tt /lib/libpthread-2.12.so 获取到信息

000000368920c130 g     F .text  000000000000001d              pthread_condattr_setclock
000000368920bcc0 g     F .text  000000000000014d              pthread_cond_broadcast@@GLIBC_2.3.2
0000000000000000       F *UND*  0000000000000000              sched_get_priority_min@@GLIBC_2.2.5
0000003689207ec0 g     F .text  000000000000004c              pthread_detach
0000000000000000       F *UND*  0000000000000000              __statfs@@GLIBC_2.2.5
000000368920ed20  w    F .text  000000000000005e              __open64

pthread_detach符号的地址与3689207ef0最为接近（这个地方有个问题，有的库导出来是相对地址，这个确实绝对，暂时没搞懂）猜测出现问题的大概率在pthread_detach函数。
反汇编objdump -D /lib/libpthread-2.12