最近在写一个写日志文件的线程时,调用了HeapAlloc/HeapFree 申请/释放堆缓冲内存。调用HeapFree释放有个条件就是,日志的空闲缓冲队列中内存块超过100个。在测试的时候,发现调用HeapFree释放内存块的时候,经常出现崩溃。

报错:其原因可能是堆被损坏,这说明**.exe中或它加载的任何DLL中有Bug。

在网上查找资料如下

1、

这是运行库文件时的错误。

解决方案:打开项目属性-->配置属性-->C/C++-->代码生成-->运行时库,改成多线程调试DLL

编译运行,然后可能会出项如下错误:

fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD


解决方案:打开项目属性-->配置属性-->常规-->项目默认值-->MFC的使用,选择“在共享 DLL 中使用 MFC”,就OK了~

如果上面这些都没用,那么就不是库文件运行的错误了,你可以试一下“清理解决方案”,然后重新生成,没准就行了。这个好像没有什么道理,可能是Visual Studio的一个bug吧

如果还不可以可以尝试下面的方法

2

一个模块一个堆,一个线程一个栈。
dll里malloc的内存,在exe里free会出错。

CRT(C运行时期库)不是使用进程缺省的堆来实现malloc(new中调用malloc)的,而是使用一个全局句柄 HANDLE _crtheap来分配内存的。这个_crtheap是在XXXCRTStartUp(CRT提供的进口点函数)中创建的。 
由于CRT静态连接,则楼主的DLL里有也有一个CRT,因此也有一个_crtheap。而在dll中的new使用dll中的_crtheap句柄分配 堆,在exe中的delete使用exe中的_crtheap释放堆,当然失败!

解决办法:
1。在DLL中输出一个函数给EXE调用,专门用来释放由DLL分配的内存;
2。用 GlobalAlloc()代替new,用GlobalFree()代替delete;
3。使用单一的堆,分配内存使用 HeapAlloc(GetProcessHeap(),0,size),释放内存使用HeapFree(GetProcessHeap(),0,p);
4。 把dll和exe的Settings的C/C++选项卡的Code   Generation的Use   Run-time   liberary改成Debug  Multithreaded   DLL,在Release版本中改成Multithreaded   DLL;这样使用一个CRT了——MSVCRT.DLL。

以下是CSDN上的讨论,同样讨论的很详细了
http://topic.csdn.net/t/20031009/17/2338051.html

以上是在网上找到的资料,今天做过详细测试,结果如下:

测试1:使用malloc/free组合来分配和释放内存,DLL中使用 malloc分配,exe中使用free释放。
我建的是Win32 DLL工程, C/C++->Code generation 设置是 Multithread DLL debug, 但是exe工程设置是MultiThread debug,所以不管怎么样,总是会抛异常. 这就间接证明了上述的描述是正确的, 若我修改exe工程设置是 MultiThread DLL debug, 那么malloc/free组合就能很好的工作起来了。

测试2:使用HeapAlloc/HeapFree组合来分配和释放内存,DLL 中使用HeapAlloc分配,exe中释放。
exe的配置还是MultiThread Debug,DLL中HeapAlloc(GetProcessheap(), HEAP_ZERO_MEMORY, 1024)分配,exe中HeapFree(GetProcessHeap(), 0, p)释放,,则还是无法正常运行,还是抛异常。若exe中设置成MultiThread DLL debug就正常运行了。

测试3:还是 使用HeapAlloc/HeapFree来进行,但是DLL中导出一个方法来释放DLL中分配的内存。
若exe配置是MultiThread Debug,无法正常运行,抛异常。若修改成MultiThread DLL debug正常运行。

所以得到的结论如下:
不管 是使用malloc/free组合还是HeapAlloc/HeapFree组合,exe工程均需要设置成MultiThread DLL debug才能正常运行起来的,CSDN上的那个讨论在这儿貌似是由出入的,而且DLL的设置不能随意修改。所以若有涉及到这种问题的,最好的办法还是在 哪个模块分配的就在哪个模块释放最好,要不然反倒会引来更多的麻烦。

from

http://blog.csdn.net/blz_wowar/archive/2008/03/13/2176536.aspx

上面这文章是我在找“...其原因可能是堆被损坏,这也说明 **.exe 中或它所加载的任何 DLL 中有 bug。”解决办法的时候找到的,学到一点,呵呵。可惜我那工程的直接原因并不是因为上面所说的(也许间接原因是),我的工程里是开启一个UI线程,UI 线程中有一个view,结果单步调试时报错“...其原因可能是堆被损坏,这也说明 **.exe 中或它所加载的任何 DLL 中有 bug。”,最后解决办法是,view需要用new创建,不能直接通过create来创建,原因是view应该是建在堆上

3

VC项目属性→配置属性→C/C++→代码生成→运行时库 可以采用的方式有:多线程(/MT)、多线程调试(/MTd)、多线

程DLL(/MD)、多线程调试DLL(/MDd)、单线程(/ML)、单线程调试(/MLd)。

Reusable Library Switch Library Macro(s) Defined
Single Threaded /ML LIBC (none)
Static MultiThread /MT LIBCMT _MT
Dynamic Link (DLL) /MD MSVCRT _MT and _DLL
Debug Single Threaded /MLd LIBCD _DEBUG
Debug Static MultiThread /MTd LIBCMTD _DEBUG and _MT
Debug Dynamic Link (DLL) /MDd MSVCRTD _DEBUG, _MT, and _DLL

其中以小写“d”结尾的选项表示的DEBUG版本的,没有“d”的为RELEASE版本。大型项目中必须要求所有组件

和第三方库的运行时库是统一的,否则将会出现LNK2005井喷。

单线程运行时库选项/ML和/MLd在VS2003以后就被废了。

/MT和/MTd表示采用多线程CRT库的静态lib版本。该选项会在编译时将运行时库以静态lib的形式完全嵌入。

该选项生成的可执行文件运行时不需要运行时库dll的参加,会获得轻微的性能提升,但最终生成的二进制代码因

链入庞大的运行时库实现而变得非常臃肿。当某项目以静态链接库的形式嵌入到多个项目,则可能造成运行时库的

内存管理有多份,最终将导致致命的“Invalid Address specified to RtlValidateHeap”问题。另外托管C++和

CLI中不再支持/MT和/MTd选项。

/MD和/MDd表示采用多线程CRT库的动态dll版本,会使应用程序使用运行时库特定版本的多线程DLL。链接时

将按照传统VC链接dll的方式将运行时库MSVCRxx.DLL的导入库MSVCRT.lib链接,在运行时要求安装了相应版本的

VC运行时库可再发行组件包(当然把这些运行时库dll放在应用程序目录下也是可以的)。 因/MD和/MDd方式不会

将运行时库链接到可执行文件内部,可有效减少可执行文件尺寸。当多项目以MD方式运作时,其内部会采用同一

个堆,内存管理将被简化,跨模块内存管理问题也能得到缓解。

结论:/MD和/MDd将是潮流所趋,/ML和/MLd方式请及时放弃,/MT和/MTd在非必要时最好也不要采用

了。

选项 说明

/MD

使应用程序使用运行时库的多线程并特定于 DLL 的版本。定义 _MT 和 _DLL,并使编译器将库名

MSVCRT.lib 放入 .obj 文件中。

用此选项编译的应用程序静态链接到 MSVCRT.lib。该库提供允许链接器解析外部引用的代码层。实际工作

代码包含在 MSVCR80.DLL 中,该库必须在运行时对于与 MSVCRT.lib 链接的应用程序可用。

当在定义了 _STATIC_CPPLIB (/D_STATIC_CPPLIB) 的情况下使用/MD 时,它将导致应用程序与静态多

线程标准 C++ 库 (libcpmt.lib) 而非动态版本 (msvcprt.lib) 链接,同时仍通过 msvcrt.lib 动态链接

到主 CRT。

/MDd

定义 _DEBUG、_MT 和 _DLL,并使应用程序使用运行时库的调试多线程并特定于 DLL 的版本。它还使编

译器将库名 MSVCRTD.lib 放入 .obj 文件中。

/MT

使应用程序使用运行时库的多线程静态版本。定义 _MT 并使编译器将库名 LIBCMT.lib 放入 .obj 文件中

,以便链接器使用 LIBCMT.lib 解析外部符号。

/MTd

定义 _DEBUG 和 _MT。此选项还使编译器将库名 LIBCMTD.lib 放入 .obj 文件中,以便链接器使用

LIBCMTD.lib 解析外部符号。

/LD

创建 DLL。

将 /DLL 选项传递到链接器。链接器查找 DllMain 函数,但并不需要该函数。如果没有编写 DllMain

函数,链接器将插入返回 TRUE 的DllMain 函数。

链接 DLL 启动代码。

如果命令行上未指定导出 (.exp) 文件,则创建导入库 (.lib);将导入库链接到调用您的 DLL 的应用程

序。

将 /Fe(命名 EXE 文件)解释为命名 DLL 而不是 .exe 文件;默认程序名成为basename.dll 而不是

basename.exe。

除非显式指定 /MD,否则将暗指 /MT。

/LDd

创建调试 DLL。定义 _MT 和 _DEBUG。

上面内容虽然说了很多解决办法,但是我的工程都符合以上要求的,选用的CRT是动态链接库。

解决问题的方向一直钻在HeapAlloc/HeapFree使用出了问题上,但是经过大量的测试,我的写法是没问题的。

最后在同事帮助下,发现原来是

这里出了问题,PLOGBUF是个LOGBUF类型的指针,这里应该是LOGBUF结构体类型的,由于疏忽写成了PLOGBUF指针。

而在第二次使用内存块时,初始化缓冲内存块使用的memset(pLogbuf,0,LOGBUF_SIZE + LOGBUF_MAX_LEN);

LOGBUF_SIZE 是等于sizeof(LOGBUF)的。这就导致了使用memset清零的时候,由于LOGBUF_SIZE + LOGBUF_MAX_LEN要大于sizeof(PLOGBUF)+LOGBUF_MAX_LEN,所以会把相邻的内存块也清零了一部分。

导致后面的HeapFree释放堆内存的时候出错。

造成这种错误报错的原因不只是选用CRT库的问题,还有可能是代码中有内存块申请、清除越界等方面的原因。

其原因可能是堆被损坏,这说明**.exe中或它加载的任何DLL中有Bug的更多相关文章

  1. 中触发一个断点 其原因可能是堆被损坏,这说明 ***.exe 中或它所加载的任何 DLL 中有 Bug

    软件中使用了DevComponents.DotNetBar2.dll MessageBoxEx.Show("ddd");运行到这句出现这个错误 : 中触发一个断点 其原因可能是堆被 ...

  2. 其原因可能是堆被损坏,这也说明 xxx.exe 中或它所加载的任何 DLL 中有 bug

    1.代码如下: string src ="abcdabcd"; char* dst = new char[8]; strcpy(dst,src.c_str()); delete[] ...

  3. 其原因可能是堆被损坏,这说明 100BloodCellSegTest.exe 中或它所加载的任何 DLL 中有 Bug。

    这个问题可能是内存空间释放了两次,比如使用cvLoadImage函数时IplImage* img = cvLoadImage(buf.c_str(),1);,注意要释放内存,但不要释放了两次cvRel ...

  4. C#.Net 如何动态加载与卸载程序集(.dll或者.exe)1----C#中动态加载和卸载DLL

    我们知道在C++中加载和卸载DLL是一件很容易的事,LoadLibrary和FreeLibrary让你能够轻易的在程序中加载DLL,然后在任何地方卸载. 在C#中我们也能使用Assembly.Load ...

  5. Windows 已在 DImageProcess.exe 中触发一个断点。

    其原因可能是堆被损坏,这说明 DImageProcess.exe 中或它所加载的任何 DLL 中有 Bug. 原因也可能是用户在 DImageProcess.exe 具有焦点时按下了 F12. 输出窗 ...

  6. 动态链接库中分配内存引起的问题-- windows已在XX.exe中触发一个断点

    动态链接库中分配内存引起的 本文主要是探讨关于在动态链接库分配的内存在主程序中释放所产生的问题,该问题是我在刚做的PJP工程中所遇到的,由于刚碰到之时感动比较诡异(这也是学识不够所致),所以将它写下来 ...

  7. C#.Net 如何动态加载与卸载程序集(.dll或者.exe)0-------通过应用程序域AppDomain加载和卸载程序集

    本博客中以“C#.Net 如何动态加载与卸载程序集(.dll或者.exe)”开头的都是引用莫问奴归处 微软装配车的大门似乎只为货物装载敞开大门,却将卸载工人拒之门外.车门的钥匙只有一把,若要获得还需要 ...

  8. 动态加载EXE和DLL

    程序中加载了一个DLL文件,但生成的EXE在脱离了DLL文件后仍然可以 单独使用,这是动态加载DLL技术.即:调用资源中的DLL. 此技术的好处:EXE可以使用DLL中的函数,但不会额外增加一 个DL ...

  9. .NET Winform 将引用的dll文件集成到exe中(转)

    Winform程序经常需要引用一些第三方dll文件,这些dll在发布后与exe文件保存在同一目录下,虽然将dll文件集成到exe中会增大文件尺寸,但程序目录会相对整洁. 下面介绍一种比较简单的集成方法 ...

随机推荐

  1. OC与Swift单例

    OC: +(instancetype)shareNetworkTools{ static id instance; static dispatch_once_t onceToken; //onceTo ...

  2. ruby中 Win32ole的各应用操作方法(word excel Outlook IE)

    Win32ole为标准Ruby发行版的一部分.Win32ole是访问Windows自动化的接口,可以让Ruby和Windows应用进行交互.具体说来Win32ole可以操作Word,Excel,IE, ...

  3. 云计算和大数据时代网络技术揭秘(十七)VOQ机制

    VOQ机制 本章介绍的VOQ是一种新型的QoS机制,目的是为了解决著名的交换机HoL难题. 但VOQ强烈依赖于调度算法,例如,一个48口的交换机,每个端口都要维护48-1个FIFO缓存队列, 一共48 ...

  4. Mac SVN ignore 等相关

    OSX自带了SVN命令行,通过终端就可以使用了. 一.SVN ignore Mac的SVN想把node_modules 忽略,即svn status时(svn st缩写)不显示node_nodules ...

  5. ArcEngine 不能再打开其他表了

    在IFeatureClass.Search()是弹出这个问题,根据网上的资料,采用 System.Runtime.InteropServices.Marshal.ReleaseComObject()或 ...

  6. AC自动机——多模式串匹配的算法思想

    标准KMP算法用于单一模式串的匹配,即在母串中寻求一个模式串的匹配,但是现在又存在这样的一个问题,如果同时给出多个模式串,要求找到这一系列模式串在母串存在的匹配个数,我们应该如何处理呢? 基于KMP算 ...

  7. PHP使用DomDocument抓取HTML内容

    有时候会有需要从一个HTML页面来分离出你需要的一些数据来进行处理. 当然自己分析文件肯定可以,但是比较快速且方便的是使用正则表达式或者DOM. 鉴于正则表达式我不熟悉,所以我打算使用DOM来完成. ...

  8. Oracle case 关键字的使用

    select e.salary, --case 语句开始 case then salary else salary end new_salary --case 语句结束,可见也和存储过程等结束方式一样 ...

  9. WIMP环境搭建

    h1 { color: #3366ff } p { font-size: 16px } body { background-color: rgb(200,200,169) } 环境说明 系统:wind ...

  10. 你不知道的JavaScript--Item15 prototype原型和原型链详解

    用过JavaScript的同学们肯定都对prototype如雷贯耳,但是这究竟是个什么东西却让初学者莫衷一是,只知道函数都会有一个prototype属性,可以为其添加函数供实例访问,其它的就不清楚了, ...