最近在写一个写日志文件的线程时,调用了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. SQL总结系列

    SQL总结系列 总结SQL基本知识.用法,并结合多年的应用对SQL有关的相关知识进行总结.希望这些分享能给大家带来一些帮助,如有不足或错误,请批评指正. 主要内容 1)编辑相关,包括:数据库的创建与删 ...

  2. Memcached 数据缓存系统

    Memcached 数据缓存系统 常用命令及使用:http://www.cnblogs.com/wayne173/p/5652034.html Memcached是一个自由开源的,高性能,分布式内存对 ...

  3. iis 7.5 0x80004005 静态文件 html、js、css 500错误

    环境:iis 7.5 win7 64位 vs2012 问题:本地环境F5直接运行,没有任何问题,发布到IIS,静态文件不能访问,出现500错误,网上找了一堆解决办法,排除路径不正确,iis全部功能勾了 ...

  4. 实现Cookie跨域共享

    实现原理:cookie是不能跨域访问的,但是在二级域名是可以共享cookie的 概念说明:站点1=a.abc.com   站点2=b.abc.com 实现步骤:1. 配置两个站点的webconfig ...

  5. ubuntu 更换系统语言,Change System Language

    1.打开设置,打开“Language Support”. 2.如果列表中没有你的语言,点击“Install/Remove Language”,下拉选择你的语言,点击“Apply Changes”. 3 ...

  6. MyBatis学习(四)、MyBatis配置文件

    四.MyBatis主配置文件 在定义sqlSessionFactory时需要指定MyBatis主配置文件: <bean id="sqlSessionFactory" clas ...

  7. VirtrualBox使用已存在的镜像创建虚拟机

    再将一个已经存在的虚拟机镜像拷贝为另一个新的虚拟机镜像后,要将该新的镜像添加到新的虚拟机中时会出现错误提示,从而导致不能创建虚拟机.例如有'D:\App\VirtualBox VMs\CentOS_6 ...

  8. C#开发分享:如何改变系统鼠标样式

    开发过程中发现需要用到改变鼠标样式(就是光标的样子),但是在网上找了很多资料,都是介绍在程序中使用,我需要的效果时在系统级使用.现在找到了,分享给大家. [DllImport("user32 ...

  9. Spring IoC容器总结(未完)

    在面向对象系统中,对象封装了数据和对数据的处理,对象的依赖关系常常体现在对数据和方法的依赖上.这些依赖关系可以通过把对象的依赖注入交给框架或IOC容器来完成,这种从具体对象手中交出控制的做法是非常有价 ...

  10. 为什么在ucos向stm32f103移植时说os_cpu_c.c中有三个函数如OS_CPU_SysTickInit()需要注释掉

    我在看os_cpu_c.c代码时对下面这段话困惑了半天总是在百度的帮助下找到了答案 /*  申明几个函数,这里要注意最后三个函数需要注释掉,为什么呢?    OS_CPU_SysTickHandler ...