文档介绍：今天碰到了一个bug,服务器在运行时会coredump在一个很灵异的地方,排除这个错误的过程,以及最后发现的错误结果很具有典型性,所牵涉到的技术也很多,拿来作为Linux调试的课程挺好的。:-P整个里面假设读者已经知道怎么用gdb,如果不知道,请参见GDBManual首先,很幸运的是,这个问题是可以很容易重现的,而且更重要的,有coredump。拿到coredump之后,惯例是查看一下调用栈:(为了避免泄漏商业秘密,所有函数名,文件名什么的都用foo啊,bar啊,foobar啊,blabla啊等等代替)。(gdb)bt#00x000000ebin??()#10x3aa1d941in??()#20x000001f8in??()#30x080cf888infoo(range=10000)atfoo/:18#40x080c1f29inbar()atbar/:423[....](gdb)infof0Stackframeat0xbfc42548:eip=0xeb;savedeip0x3aa1d941calledbyframeat0xbfc4254cArglistat0xbfc42540,args:Localsat0xbfc42540,Previousframe'sspis0xbfc42548Savedregisters:eipat0xbfc42544(gdb)f3#30x080cf888infoo(range=10000)atfoo/:1818return((u32)random())%range;相当的灵异,栈上的0,1,2都是,一个返回地址怎么可能是0×1f8,而且,coredump的原因是因为eip跑飞到了0xeb。到frame3的时候看起来正常了,但是出错的地方在random这种简单的库函数上。不过既然frame3往下的部分都是好的,我们有理由认为栈并没有被搞坏。因为GDB在显示调用栈的时候可能会把一些不正确的调用栈也显示出来,我们干脆直接看内存:(gdb)x/10w$esp0xbfc42544:0x3aa1d9410x000001f80x080cf8880x095829300xbfc42554:0x0833f0380xbfc426780x080c1f290x000027100xbfc42564:0x0823747f0xb7ca168c看加粗的部分:这里就是frame3返回地址,而上面的东西,就是bt显示出来的frame1和frame2了,而frame0就是当前的eip了:它跑飞到了0xeb。GDB果然在显示栈的时候做了手脚。OK,我们反汇编看看这个返回地址,到底干了什么:(gdb)disassemble0x080cf888Dumpofassemblercodeforfunction_Z6foom:0x080cf85c<_Z6foom+0>:push%ebp0x080cf85d<_Z6foom+1>:mov%esp,%ebp0x080cf85f<_Z6foom+3>:push%ebx0x080cf860<_Z6foom+4>:sub$0x4,%esp[…]0x080cf87a<_Z6foom+30>:movl$0x0,0xfffffff8(%ebp)0x080cf881<_Z6foom+37>:jmp0x80cf893<_