一个core的完整背景

来源:互联网 发布:mac怎么使用搜狗 编辑:程序博客网 时间:2024/05/22 17:24
一个core的完整背景
2010年12月10日 下午 3:56

前言

前段时间,百度某产品线的一个模块在重启的时候出了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++程序尤其要注意到这一点。

因此当你优雅的通过析构清理了所有内容的时候,很可能还有莫名的线程在等待着走向那非法的地址空间。

 

(全文完)

 


类别:测试技术||添加到搜藏|分享到i贴吧|浏览(946)|评论 (0)
 
上一篇:静态代码分析——字符串    下一篇:Perl单元测试
 
原创粉丝点击