前言 前段时间,百度某产品线的一个模块在重启的时候出了core,本文尝试将这个core, 以及core引发的技术上的思索,完整的勾勒出来。 充分挖掘core文件 core文件时第一“犯罪现场”,它会告诉你很多很多事情。一个优秀的侦探是不会放过core中的任何蛛丝马迹的。那么从core文件开始:
(gdb) bt #0 0x000000302af70b9a in memcmp () from /lib64/tls/libc.so.6 #1 0x000000000042bc64 in product::KeyMutex::UnlockKey (this=0x7fbfffec98, key=@0x41e001f8) at KeyMutex.h:171 #2 0x000000000042a457 in ~Locker (this=0x41e001f0) at KeyMutex.h:198 #3 0x0000000000426298 in product::Someauthority::ItemDel (this=0x7fbfff5c50, key=@0x41e00350) at Someauthority.cpp:789 #4 0x000000000043032b in product::Someprocessor::Someupd (this=0x7fbfff4a40, pReqPack=0x2a9b6b5f90, luCmStamp=1281691520) at Someprocessor.cpp:462 #5 0x000000000042f38b in product::Someprocessor::Proc (this=0x7fbfff4a40) at Someprocessor.cpp:264 #6 0x000000000041d8a7 in product::Processor::Process (this=0x7fbfff4a40) at Processor.cpp:75 #7 0x000000000041dd21 in product::Processor::Somecallback () at Processor.cpp:111 #8 0x0000000000455004 in eppool_consume (pool=0xaf41f0, data=0xa5cea0) at eppool.cpp:455 #9 0x0000000000454e60 in _eppool_workers (param=0xa5cea0) at eppool.cpp:410 #10 0x000000302b80610a in start_thread () from /lib64/tls/libpthread.so.0 #11 0x000000302afc6003 in clone () from /lib64/tls/libc.so.6 #12 0x0000000000000000 in ?? ()
看来core在了memcmp这个函数中了。 可惜的是memcmp函数在libc中,由于libc没有-g编译,看不到足够的debug信息。 (gdb) f 0 #0 0x000000302af70b9a in memcmp () from /lib64/tls/libc.so.6 (gdb) inf f Stack level 0, frame at 0x41dffc20: rip = 0x302af70b9a in memcmp; saved rip 0x42bc64 called by frame at 0x41dffce0 Arglist at 0x41dffba8, args: Locals at 0x41dffba8, Previous frame's sp is 0x41dffc20 Saved registers: rbx at 0x41dffbe8, rbp at 0x41dffbf0, r12 at 0x41dffbf8, r13 at 0x41dffc00, r14 at 0x41dffc08, r15 at 0x41dffc10, rip at 0x41dffc18
我关心的是Previous frame's sp is 0x41dffc20, 因为我想看下调用memcmp函数的压栈的信息。 (gdb) x/10x 0x41dffc20 0x41dffc20: 0x41dffc70 0x00000000 0x0046f67a 0x00000000 0x41dffc30: 0x00000000 0x00000002 0x00a65b10 0x00000000 0x41dffc40: 0x00a65bc8 0x00000000
看了下栈的数据中没有全是0的,为何会core呢?
看下memcmp的原型: int memcmp(const void *s1, const void *s2, size_t n); 3个参数压栈,如果参数都没有问题,core在了memcmp中,难道是memcmp的bug? 一般情况下,x86_64的函数调用的参数传递规则是: 参数小于6个的时候,通过寄存器传递参数,顺序是rdi,rsi,rdx,rcx,r8,r9, 参数个数大于6个时候,才使用堆栈传递参数
看一下frame1的函数的反汇编: (gdb) disassemble product::KeyMutex::UnlockKey 我这里截取需要内容: 0x000000000042bc44 : mov 0xffffffffffffffe8(%rbp),%rdx 0x000000000042bc48: mov 0xffffffffffffffc4(%rbp),%eax 0x000000000042bc4b: shl $0x4,%rax 0x000000000042bc4f : mov %rax,%rsi 0x000000000042bc52 : add 0x70(%rdx),%rsi 0x000000000042bc56 : mov 0xffffffffffffffe0(%rbp),%rdi 0x000000000042bc5a: mov $0x10,%edx 0x000000000042bc5f: callq 0x410c38
这个0x410c38就是memcmp的函数地址,可以通过objdump查到。 那么接着看下寄存器的内容: (gdb) p /x $rdx $1 = 0x2 (gdb) p /x $rsi $2 = 0x0 (gdb) p /x $rdi $3 = 0x41e001f8
可以清楚的看到第2个参数的内容是0x0. 根据memcmp的原型,第二个参数传入的就是null指针了。
这个就基本定位问题了。 是因为memcmp第二个参数填写0导致的core。
在我们不了解一个模块具体结构的情况下,core信息基本足够我们分析到什么原因,什么地方导致的core。 我们要充分利用core信息。 逻辑上的原因 这里简单分析下逻辑上的原因:
core在了这个地方: if( 0 == memcmp(&key, &this->_pSlots[i], sizeof(key)))
根据我们之前的分析,第2个参数为null导致的core。 整体的流程是这样的:main退出,导致Someauthority析构,导致KeyMutex析构,导致_pSlots 被写0.导致另一个线程在读的时候core了。
对于为何main退出了线程还没有结束,先简单说下,程序在运行时的入口函数一般不是main。举个例子: 我写了一个很简单的d.cpp(程序我在后面描述),我们看下d编译后的一些信息: readelf -h d ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Entry point address: 0x4003b0
这个Entry point时实际的入口地址。 这个地址的函数时: 00000000004003b0 <_start>:
因此main函数退出的时候,thread并没有被清理掉。 这方面的更详细的分析我后面再给出。
线程的终结 继续分析线程的终结的问题。 在程序正常退出的情况下,线程是如何退出的。 为了证实线程和main的关系问题,我写了个小程序:就是上面说到的d.cpp: #include #include "stdio.h" #include "stdlib.h" #include "unistd.h" #include "pthread.h"
class MyC{ public: MyC(); ~MyC(); };
MyC::MyC(void){ return; }
MyC::~MyC(void){ while(1) sleep(1); return; }
void *server_thread(void* nu){ while(1){ sleep(1); fprintf(stderr,"."); } }
int main(){ MyC myc; pthread_t ServerThread; int pid = pthread_create(&ServerThread, NULL, server_thread, NULL); return 0; }
程序是为了证实,main函数结束后,线程仍然会在运行。我们在析构函数中无限sleep,让程序在退出main后暂停。 如果线程继续运行,会不断有屏幕打印。 编译后运行,证实了这个说法。 ./d ...........
我们后面的分析也基于这个函数,因为其足够简单。 仍然从头开始: readelf -l d
Elf file type is EXEC (Executable file) Entry point 0x4005b0
我们得到了程序的入口地址,这个地址是不会变的。然后我们gdb一下d,run起来后停下来。 (gdb) disassemble 0x4005b0 Dump of assembler code for function _start: 0x00000000004005b0 <_start+0>: xor %rbp,%rbp 0x00000000004005b3 <_start+3>: mov %rdx,%r9 0x00000000004005b6 <_start+6>: pop %rsi 0x00000000004005b7 <_start+7>: mov %rsp,%rdx 0x00000000004005ba <_start+10>: and $0xfffffffffffffff0,%rsp 0x00000000004005be <_start+14>: push %rax 0x00000000004005bf <_start+15>: push %rsp 0x00000000004005c0 <_start+16>: mov $0x400780,%r8 0x00000000004005c7 <_start+23>: mov $0x400720,%rcx 0x00000000004005ce <_start+30>: mov $0x4006da,%rdi 0x00000000004005d5 <_start+37>: callq 0x400560 0x00000000004005da <_start+42>: hlt 0x00000000004005db <_start+43>: nop End of assembler dump.
可以看到,程序的入口是_start,这个是和编译器相关的。 在进行了一坨寄存器处理后,调用了一个函数。 继续看一下0x400560是啥函数:
(gdb) x/i 0x400560 0x400560: jmpq *1050242(%rip) # 0x500be8 <_GLOBAL_OFFSET_TABLE_+24>
函数的第一句话就是跳转到一个地址。 后面的注释也说明了是got表中的一项。got表中存放的一般都是地址信息。 那么这个地方存放的应该是需要跳转的下一个函数的地址。继续看一下地址0x500be8放的是什么内容:
(gdb) x/2x 0x500be8 0x500be8 <_GLOBAL_OFFSET_TABLE_+24>: 0x8a21c3e0 0x0000003b
地址一下子变的很大,这里使用的是64位系统。这个高的地址很可能是系统函数。看下这个地址是啥函数:
(gdb) x/i 0x0000003b8a21c3e0 0x3b8a21c3e0 <__libc_start_main>: push %r12
这个函数就是glibc中的著名的__libc_start_main, 这是一切程序的第一个main。
我们看下这个函数的内容: (gdb) disassemble 0x0000003b8a21c3e0 我只截取关注的内容: 0x0000003b8a21c4aa <__libc_start_main+202>: mov 0x14(%rsp),%edi 0x0000003b8a21c4ae <__libc_start_main+206>: mov 0x8(%rsp),%rsi 0x0000003b8a21c4b3 <__libc_start_main+211>: mov 0x0(%rbp),%rdx 0x0000003b8a21c4b7 <__libc_start_main+215>: callq *0x18(%rsp) 0x0000003b8a21c4bb <__libc_start_main+219>: mov %eax,%edi 0x0000003b8a21c4bd <__libc_start_main+221>: callq 0x3b8a230c70
3个连续的mov显然是在准备参数,callq *0x18(%rsp) 这个地方才是真正的调用的main函数。 可以看到,在main函数返回后还远没有结束, 首先继续调用了exit来结束程序。 看下exit的内容: (gdb) disassemble 0x3b8a230c70 Dump of assembler code for function exit:
0x0000003b8a230d26 : callq 0x3b8a28f070 <_exit>
在函数_exit中,看到了syscall,在这里交给了内核,内核负责完成进程结束的处理。所有的线程就在这里结束了。
后记 对于C和C++程序,在main结束后并不意味着程序运行的结束。 当然在main被运行前也并不意味着程序没有开始运行。 C++程序尤其要注意到这一点。 因此当你优雅的通过析构清理了所有内容的时候,很可能还有莫名的线程在等待着走向那非法的地址空间。
(全文完) |
一个core的完整背景
最新推荐文章于 2019-06-12 13:46:00 发布
一个core的完整背景
2010年12月10日 下午 3:56