一个程序员的修炼之路

对一个C++内存泄露案例进行的思考

一个堆破坏的老故事还记得第一次碰到堆破坏的时候，大概十年前了，当时在学校开发一个Wireshark插件，可是有一个问题我久久未能解决: 我修改后的Wireshark运行的时候偶尔启动的时候会出现程序崩溃，那时候也不会用Windbg, 后来用Visual Studio启动Wireshark, 也是偶尔报错，这个时候可以看到堆栈，只记得当时是在一个很正常的内存分配或者释放的时候出现崩溃。那么总结为两点：偶尔重现，那么也就是我们常说的还能跑起来，跑不起来那么就重启进程，重启进程无效，那就万能方法重启机器。这

如果在Windows中编程应该了解一些Windows的内存管理，而堆(Heap)也属于内存管理的一部分。Windows Heap下图参考<<Windows高级调试>>所画，并做了一些小小的修改。可以看出来程序中对堆的直接操作主要有三种:进程默认堆。每个进程启动的时候系统会创建一个默认堆。比如LocalAlloc或者GlobalAlloc也是从进程默认堆上分配内存。你也可以使用GetProcessHeap获取进程默认堆的句柄，然后根据用这个句柄去调用HeapAlloc达到在系统

有一定C++开发经验的同学大多数踩过内存破坏的坑,有这么几种现象:比如某个变量整形，在程序中只可能初始化或者赋值为1或者2, 但是在使用的时候却发现其为0或者其他的情况。对于其他类型，比如字符串等，可能出现了一种出乎意料的值！程序在堆上申请内存或者释放内存的时候，在内存充足的情况下，居然出现了堆错误。当出现以上场景的时候，你该思考一下，是不是出现了内存破坏的情况了。而本文主要通过展示和分析常见的三种内存破坏导致覆盖相邻变量的场景，让读者在碰到类似的场景，不至于束手无策。而对于堆上的内存破坏，很常见并

本人在之前已经写过四篇关于Windows中如何查找内存泄露的方法，基本上可以说可以帮你找到内存泄露的问题所在。<<Windows内存泄露分析之DebugDialog>><<Windows程序内存泄漏(Memory Leak)分析之Windbg>><<Windows程序内存泄漏(Memory Leak)分析之UMDH>><<vmmap分析内存泄露问题>>那么为什么要写这篇文章呢？本人在逛知乎的时候，

vmmap是sysinternals工具集中的一个工具，主要用于分析一个进程的虚拟内存和物理内存的使用情况。更有效的是，可以通过对比两个不同时间的内存使用情况的Snapshot，来查找内存泄露问题。vmmap介绍当你用vmmap去查看一个正在运行的进程的时候。可以看到如下图，不同类型的内存使用采用不同的颜色标明。VMMap主要列举了以下几种类型的内存使用情况：Free: 图中显示137434599232K，是不是被吓到了。这个一般是指虚拟地址空间。每个进程都有自己的虚拟地址空间，比如32位的一般为4

在上一篇文章<<栈溢出的场景分析和建议>>中，本人分享了如何查找程序Crash的函数调用栈，然后通过代码审查找到栈溢出的原因。但是却有一些场景通过代码审查不易找到问题，比如如下两点:函数的调用逻辑复杂，且触发逻辑依赖于输入样例。这样通过代码审查是很难看出问题所在的。当触发的栈溢出问题在非自己公司开发的第三方库中，无法获取源代码，也不易看出问题。那么针对上面这两点，都需要一个东西去做辅助分析，那就是触发栈溢出的输入内容（这的所谓输入内容不是指用户在交互界面输入，而是指触发这个

Windows中内存泄露的文章本人已经写过两篇<<Windows程序内存泄漏(Memory Leak)分析之UMDH>>和<<Windows程序内存泄漏(Memory Leak)分析之Windbg>>。如果有丰富调试经验的同学会发现，很难用一种工具或者方法去分析所有的场景，尤其当工程庞大的时候。本文要介绍的就是微软提供的DebugDialog, 他可以用于分析Hang，性能问题，内存泄露问题等等。对于内存泄露问题，DebugDialog分析后会给出一个完整的R

场景介绍有时候当你收到一个dump后，大多数情况可以通过k命令查找到导致栈溢出的函数。但是本文要讲的是，曾经碰到过的栈溢出(stackoverflow), 却无法直接通过k命令查看到当前的函数调用栈。 下面将介绍一个简单的方法，找到导致栈溢出的函数。样例代码先声明下，因为产品的实际分析不能够通过网络分享。下面的样例代码，实际上不会导致在上一章场景介绍中提到的问题，可以直接通过crash的栈查找到代码，本文只是通过这个例子来讲解如下场景的分析思路: 如果栈溢出了，通过k命令却无法查找到函数调用栈。#i

之前本人写了一篇<<Windows程序内存泄漏(Memory Leak)分析之Windbg>>。这种方法有一定的局限性:实践证明，当程序复杂，内存频繁的申请释放，通过UMDH对比的文件将会非常的大，并且很难直接看出内存泄露所在。UMDH在收集信息的需要符号文件，不太适合于在客户的机器上进行操作。调试方法很难一通百用，因为不同的工具都有自己的局限性，也有适合自己的分析场景，这个取决于碰到的问题。那么本文来介绍一种，使用Windbg分析内存泄露的方法。样例代码这个样例代码中

终端产品一般部署在客户的环境中，那么奇奇怪怪的问题也就容易出现了。比如Windows产品进程为什么忽然停止了？ 这个时候稍微有些经验的程序员会做出以下判断：中型的产品中，代码比较复杂。是不是程序中有什么退出逻辑，没有注意到？是不是程序崩溃了，比如资源不足或者代码bug?是不是系统中的其他程序关闭了我们的进程？比如客户的脚本或者其他的软件。是不是程序中有什么退出逻辑，没有注意到？这种情况一般通过Debug Log 可以进行追踪。比如常见的程序退出的时候会有Log记录。是不是程序崩溃了，比如资源

无论是在编写Windows程序还是Linux程序，都可能存在句柄泄露的问题。在Linux中一般来说一个进程的fd使用是有上限的，可以使用ulimit命令进行上限查看，当出现fd泄露的时候，可能会出现socket创建失败,文件打不开等问题。Windows类似，本文主要阐述了对Windows中的句柄泄露的追踪方法。Windows句柄泄露在Windows开发中，当调用Windows API，比如CreateFile, CreateEvent, CreateThread 等API的时候，都会返回一个句柄Hand

小木发现线上的程序通过任务管理器发现内存不断的增长，怀疑是不是内存泄漏呢？用户态内存泄漏可能是句柄泄漏，堆内存泄露，Socket, GDI对象等等。而对于C++程序员来说，碰到最多的无疑是堆内存泄露：也就是通过malloc或者new从堆上申请的内存，使用完成后，并没有释放，导致程序使用的内存越来越多。小木找到了一个分析利器UMDH: 这也是Windbg工具集中的其中一个利器，它可以在一个时间点记录程序的当前程序使用的堆内存申请的信息，过一段时间后再记录一次程序使用的堆内存申请的信息，然后比较两次的结果来找

配置PDB符号文件服务器的想法刚入职的小木，前不久刚刚解决了一次crash问题《Windbg分析程序崩溃实践》。 小木没有松懈，继续进行项目代码和Debug技术的学习，同时也思考了一个问题**“产品每隔一段时间就会发布新的版本，当出现Crash问题的时候得手动去拷贝响应版本的pdb文件到本机进行调试，有没有什么方式可以实现自动化呢？”** 嗯，小木是一个合格的程序员，程序员就是致力于让重复的工作自动化。小木继续想，如果能把产品每次发布的pdb文件存储到一个服务器，就像微软的symbol server

1. 项目场景本故事纯属虚构。初入职场的小木，负责维护一个博客系统，后端采用C++编写，部署在Windows服务器上。刚刚熟悉完产品的小木，接到了后台服务的报警，服务器后端偶尔会程序崩溃。刚开始小木还有点慌张，脑子里面浮现出各种问题，这个是程序的bug吗？茫茫的代码如何寻找问题？log能看到线索吗？当冷静下来后，小木忽然想起前几天看的两篇文章<<Windbg调试----Windbg入门>>和<<Windows程序Dump收集>>，还没动手过呢，正好练习练习

发布给客户的程序，出现问题后，通过Debug Log经常很难分析出原因。比如说程序崩溃，程序死锁，内存泄漏等，这个时候从客户那里收集程序Dump，本文主要描述了几种收集dump的工具。adplus收集Dumpadplus是windows 调试工具集中的一个工具，安装了WDK或者Windbg后在安装目录都有。现在很多的OS 都是64位了，但有时候Crash的程序是32位，有时候Crash的程序是64位

Windbg中局部变量显示不正确

Windbg简单来说就是一个Windows下对用户态/内核态的程序进行调试，以及对Core Dump文件的分析。对于Crash，资源泄露，死锁等问题的分析，Windbg是一个强有力的利器。相关资料本人也是在维护和开发产品的过程中使用过Windbg，但并未对Windbg进行过系统和深入的学习，也通过这一系列的博客来完善自己对Windbg以及周边知识的理解与使用。我也列出自己正在或者即将阅读的书/资料与

在Windows中，让程序模块化实现的一种方式，就是让其实现为动态链接库。然后在主程序启动的时候隐式或者显示的去加载动态链接库。但是如果不恰当的编写动态链接库的DllMain函数，将会引起意想不到的Bug哦，比如典型的Loader Lock死锁问题。这不，我们产品中就碰到了一个由于Loader Lock而引起的Bug....1. 背景介绍      当主程序在启动的时候，隐式或者显

在对代码进行测试的时候，发现进程占用了100%的单核CPU资源。并且发现在另一个环境，这个进程占用了50%的CPU资源，因为在这个环境中是2核的CPU。而此时这个进程还并没有处理任何的数据，也就是说会有一个线程一个只占用一个CPU核的资源。对于这个问题研究的方法主要用到了两个工具：Process Explorer和Windbg。使用Process Exporer查找占用CPU资源的线程博主采用了一个

在调试程序的时候，可能经常会有这样的需求，让一个线程在特定的时候才让其开始执行或者暂停执行。比如复杂的多线程导致死锁的问题，又或者多线程中的Race Condition 导致程序执行异常等。很多时候，我们可以借助编写调试代码来达到多线程的调试，可是有些情况下调试的执行粒度是指令级别的，那么这个时候我们得借助调试利器Windbg了。本文我们将以《C/C++编程教训—-函数内静态类对象初始化非线程安全（

问题描述在一年前，发现产品的windows service总是崩溃，但每次用windbg attach或者adplus产生dump，总是不能捕获到程序出错时候的栈，而且crash的时候只能看到少数甚至只剩一个线程。后来用windbg单步调试终于找到的罪魁祸首，原来是出错在strcpy_s这个函数。但是为什么直接用windbg attach或者adplus没法获取第一现场呢？当程序比较简单的时候