实习心得（三）gdb调试

        去搜狗实习之前，遇到了一位强大的老师--操作系统的陈向群老师，她让我们学着在linux下用vim写程序看程序，用gdb调试程序，学些makefile，用make命令编译程序。只是那时候只觉得这样很不方便，没有意识到gdb的强大。也只是很浅了学了学，觉得不好用。

        开始接手antispider的时候，听到了程序出core了，有core文件，那时候不知道老大在说什么，默默地回去问了度娘，然后了解了core文件。并学着结合core文件，使用gdb调试：gdb [exec file] [core file] 这时候得出的结果定位到了出问题的地方，层层深入，可以使用f 查看对应哪一层，然后up和down分别可以查看上一层调用或下一层；bt进一步查看详细显示crash信息。很多时候到这步就可以看出错误的原因了，但是有些情况下无法看出问题的所在。

       我当时core的地方并没有段错误，指针越界这些情况。但是我要进入到一个函数的时候出现了错误，函数的指针指向一个无效的地址，这让人很崩溃和郁闷，因为都不知道为何突然指向了一个无效的地址。调用函数之前还是正确的，就运行完调用这句话就出错了。那次请到了一位大牛来解决的，大牛不只是看到bt这一层信息就行了，他使用了相关的查看寄存器信息的info reg，获取函数返回地址，然后发现函数地址是一个很大的偏移量且不正确，他又反汇编了出错的函数disass func_name，（disassemble 不带参数，默认的反汇编范围是 所选择帧的pc附近的函数；单个参数, 就是pc, 当然也可以是函数名，因为函数名 也是一个 地址; 这样范围就是该pc附近的函数；两个参数，就是内存地址范围）。然后他立马指出函数执行完某行代码后，整个寄存器值减一个很大的值导致问题所在，这里应该申明了一个占用很大空间的临时变量，导致栈空间溢出。然后他说一个线程的栈空间默认为2M空间。于是我告知我创建了一个多大的数据结构，果然我将该结构使用动态内存分配，错误解决。

       这个事情让我觉得，原来以前学习的计算机组成与结构，操作系统里面的程序内存地址空间的分配这些都是很重要的。首先计算机组成与结构中告诉你每个寄存器值的含义，结合内存地址空间分配，可以很快了解到出错的内存地址变化应该哪些可能操作引起的，异常在什么地方。这里引用一下一张图片：而图中stack中存储的就是主函数中后的下一条指令（函数调用语句的下一条可执行语句）的地址，然后是函数的各个参数，函数中的局部变量。

       gdb调试不只是出错了，有core文件有帮助，对于程序堵住了陷入死循环也很有帮助，所以测试的时候保留现场很重要，不要看到你的程序死了没跑了就kill掉。这时候可以用gdb -p PID，查看程序运行的进程，如果是多线程程序接着使用info threads指令，查看是停在哪个线程，然后进一步thread ID查看具体线程停在哪个函数信息。这个真的很有效，尤其是当你的程序产生了几十G甚至更大的log信息的时候，你不知道停在哪里。你也很难入手查询。

      当然gdb的强大肯定不只这些小小的方面，这只是我这个“小人”体会到的几点。于牛人们的体会，可以看牛人们的文章，或者以后会在工作中遇到请教。也可以自己研究研究。