anzhsoft的技术专栏

如何解决一个valgrind和gpreftools都检查不出的”内存泄露“？

本周遇到了好几个core都很有典型性。在这里和大家分享下。相信有过Linux编程经验的人，肯定都遇到过。感觉周围人很多对core有天然的恐惧感，尤其对刚入行不久的同学来说。当然了，也有工作好几年看到core也束手无策的。今天就分析一下，core，其实大部分都是很容易解决的。如果一个core很难以复现，那么说明还是很复杂的，算是Corner case，可能需要很长时间，脑子里要有很好的运行时状态才可以（阅读源码，学习的是逻辑；将源码对应到运行时的状态，分析一些状态机的转换，再去分析可能会发生的情况）。相信前

本文主要讲解动态库函数的地址是如何在运行时被定位的。首先介绍一下PIC和Relocatable的动态库的区别。然后讲解一下GOT和PLT的理论知识。GOT是Global Offset Table，是保存库函数地址的区域。程序运行时，库函数的地址会设置到GOT中。由于动态库的函数是在使用时才被加载，因此刚开始GOT表是空的。地址的设置就涉及到了PLT，Procedure Linkage Table，它包含了一些代码以调用库函数，它可以被理解成一系列的小函数，这些小函数的数量其实就是库函数的被使用到的函数的数量

实际上，Linux的调试方法非常多，针对不同的问题，不同的场景，不同的应用，都有不同的方法。很难去概括。本篇文章主要涉及本专栏还没有涵盖，但是的确有很重要的方法。本文主要包括动态库注入调试；使用ltrace命令处理动态库的调试；使用strace调试系统调用的问题；Valgrind的简要介绍。

作为工作几年的老程序猿，肯定会遇到coredump，log severity设置的比较高，导致可用的log无法分析问题所在。 更悲剧的是，这个问题不好复现！所以现在你手头唯一的线索就是这个程序的尸体：coredump。你不得不通过它，来寻找问题根源。本文通过一个常见的coredump，逐步讲解如何发现导致coredump的原因

关于C++虚函数，很多博文从各个角度来探究虚函数是如何实现的，或者说编译器是如何实现虚函数的。本文通过GDB来从另外一个角度来理解C++ object的内存布局，一来熟悉语言背后编译器为了实现语言特性为我们做了什么；二来熟悉使用GDB来调试程序。 同时，本文也将对如何更好的理解C++语言提供了一个方法：使用GDB，可以很直观的理解编译器的实现，从根本上掌握C++！我们不单单只会开车，还应该知道车的内部的构造。

上一篇文章《Linux Debugging:使用反汇编理解C++程序函数调用栈》没想到能得到那么多人的喜爱，因为那篇文章是以32位的C++普通函数（非类成员函数）为例子写的，因此只是一个特殊的例子。本文将函数调用时的参数传递方法进行一下总结。总结将为C++普通函数、类成员函数；32位和64位进行总结。        本文对分析栈溢出导致的coredump十分有益。

没想到《Linux Debugging:使用反汇编理解C++程序函数调用栈》发表了收到了大家的欢迎。但是有网友留言说不熟悉汇编，因此本书列了汇编的基础语法。这些对于我们平时的调试应该是够用了。    本科时候大家学的基本上都是Intel的8086汇编语言，微软采用的就是这种格式的汇编。GCC采用的是AT&T的汇编格式, 也叫GAS格式(Gnu ASembler GNU汇编器)。1、寄存器命名不同AT&TIntel说明%eaxeaxIntel的不带百分号2、操作数顺序不同

拿到CoreDump后，如果看到的地址都是？？？？，那么基本上可以确定，程序的栈被破坏掉了。GDB也是使用函数的调用栈去还原“事故现场”的。因此理解函数调用栈，是使用GDB进行现场调试或者事后调试的基础，如果不理解调用栈，基本上也从GDB得不到什么有用的信息。本文还可以帮助你深入理解C++函数的局部变量。我们学习时知道局部变量是是存储到栈里的，内存管理对程序员是透明的。通过本文，你将明白这些结论是如何得出的。