服务器程序从 Windows 系统移植到 Linux/x86_64 平台时总是崩溃?

清华大学出版社的《高效 C/C++调试》一书给出了回答：
我们的服务器程序最初是为 Windows 系统开发的， 第一次将它移植到 Linux/x86_64 平台时，它在回归测试中十次会崩溃八次，且仅在多处理器机器上出现这种现象。这种症状强烈地暗示着存在多线程问题。核心转储文件显示，系统库 libc.so 的内存管理器中的函数 malloc_consolidate 内部出现了段错误。考虑到该函数正尝试合并相邻的空闲内存块，我们怀疑应用程序可能以某种方式破坏了堆。

我们打开了内存管理器的调试功能，方法是设置环境变量 MALLOC_CHECK_=2（参见第 10章）。内存调试器捕获到了一个问题—一个内存块被释放了两次，这导致程序崩溃。我们确定了这个内存块上的数据对象，发现它被多个线程共享。然而，对象的所有权是通过引用计数严格控制的，这是共享数据的标准实现方式。当引用计数减少到 0 时，对象将被删除。这个处理在其他平台上得到了良好的执行并且已经通过了全面的测试。那么，为什么在新的平台上会出现问题呢？为了验证引用计数是否按照设计工作，我们在修改对象引用计数的函数中插入了日志语句。

class AtomicLong { public: ... long operator++() throw() { return AtomicIncrement(&mnAtomicLongData); } long operator--() throw() {return AtomicDecrement(&mnAtomicLongData); } ... private: long mnAtomicLongData; }

virtual void AddRef() const throw(void* ipObject, AtomicLong& irRefCount) { RefCountLog("AddRef", ipObject, irRefCount); ++irRefCount; }

virtual void Release(void* ipObject, AtomicLong& irRefCount)const throw() { RefCountLog("Release", ipObject, irRefCount); if (--irRefCount == 0) {

// 这是最后一次引用free(ipObject);

} }

void RefCountLog(const char* ipFunc, void* ipObject, long iRefCount) { FILE* lpFile = GetLogFile(); fprintf(lpFile, "tid= %ld\tFunction=%s\tObjectID=0x%lx”

“\tRefCount=%ld\n",

pthread_self(), ipFunc, ipObject, iRefCount);

// 检索调用者的堆栈跟踪

const int max_stack_depth = 32; void* lTrace[max_stack_depth]; int lTraceSize = ::backtrace(lTrace, max_stack_depth); _ASSERT(lTraceSize > 0);

// backtrace_symbols 分配一块内存来存储符号

char** lpFunctionNames = ::backtrace_symbols(lTrace, lTraceSize); for(int i=0; i<lTraceSize; i++) { _ASSERT(lpFunctionNames[i] != NULL); fprintf(lpFile, "\t[%d] %s\n", i, lpFunctionNames[i]); } }

日志函数记录了发起调用的线程 ID、回溯、对象的地址、当前的引用计数以及对对象的操作。当问题再次出现时，我们在日志文件中得到了一系列的记录。通过脚本解析这些输出，发现 AddRef和 Release 函数被调用的次数与设计时预期的一致，但对象的引用计数并未反映出这一点。这提示我们引用计数器本身（即 AtomicLong 类中的长整数）的递增和递减操作可能存在问题。这个类的递增和递减运算符是通过调用 AtomicIncrement 和 AtomicDecrement 函数实现的，这两个函数都是用汇编语言编写的， 这些函数本应具有原子性和线程安全性。但是，对这些函数的进一步代码审查引发了我们对它们在新平台上执行的正确性的怀疑。经过更严格的单元测试，我们发现在高负载下，这些函数确实存在问题。修复这个错误后，测试就一直运行得很好。

因此，在这种情况下，日志记录的方法帮助我们将问题定位到了引用计数器的原子递增和递减代码上。