memset函数导致内存泄露的问题

我们一般常说的内存泄漏是指堆内存的泄漏。程序从堆中分配的内存使用完毕后必须显式释放,否则这块内存就不能被再次使用,即这块内存泄漏了。内存泄漏导致软件在运行过程中占用越来越多的内存,程序的效率会越来越低,从而影响用户的体验,失去市场竞争力。

 为了预防内存泄漏我们要求程序使用malloc、new等函数从堆中分配的内存必须在使用完后调用free、delete函数释放该内存。但是如果指向该内存指针的值被修改了,不再指向该内存了,那么即使调用free、delete函数也不会释放该内存,memset函数就会导致这种情况的发生。先来看一下memset函数的声明:

void *memset(void *s, int ch, size_t n); //将s中前n个字节用ch替换并返回s

假如指针s指向的类对象包含指针成员变量,那么在清零的过程中,就会将该指针的值置为0,不再指向原内存空间,原内存空间得不到释放导致内存泄漏。小编在近期的单元测试中就遇到了这个问题。问题发生在使用memset函数对包含string类型的结构体对象进行清零操作。我们先看一下的string类的构造和析构函数的简单实现:

class MString

{

public:

MString(const char *data = NULL);

……….

~MString();

private:

char *str_data;

};

MString::MString(const char *data)

{

try

{str_data = new char[strlen(data) + 1]; }

catch(const bad_alloc &e)

{ cout<<e.what(); abort(); }

strcpy(str_data, data);

}

MString::~MString()

{

delete[] str_data;

}

string类的构造函数在构造string对象时,str_data指针会指向堆中字符串长度加1大小的内存空间,而使用memset函数对string类型对象清零后str_data的值变成了0,指向的原内存空间在析构函数中不会被释放,导致内存泄漏。

因此我们可以得出结论:不要轻易零初始化string、vector等STL标准容器及具有动态内存管理的类。

时间: 2024-10-10 00:06:35

memset函数导致内存泄露的问题的相关文章

Andorid 内存溢出与内存泄露,几种常见导致内存泄露的写法

内存泄露,大部分是因为程序的逻辑不严谨,但是又可以跑通顺,然后导致的,内存溢出不会报错,如果不看日志信息是并不知道有泄露的.但是如果一直泄露,然后最终导致的内存溢出,仍然会使程序挂掉.内存溢出大部分是关于图片的请求,然后又没有及时的释放内存,而导致的内存泄露. 下面是几种常见的导致内存泄露的写法.有些是收集的别的地方的,我也是看到才知道自己写错了,分享一下吧 1.单例造成的内存泄漏 大家都喜欢用Android的单例模式,不过使用的不恰当的话也会造成内存泄漏.因为单例的静态特性使得单例的生命周期和

TransitionDrawable使用不当导致内存泄露

最近要做类似网易云音乐背景高斯模糊的效果, 同时也想让背景变化时不要那么生硬, 就是下面这个效果 Google一番后决定用TransitionDrawable, 由于是配合UniversalImageLoader使用, 所以只需要实现一个BitmapDisplayer作为UIL的配置项就行了. 最初的代码是这样写的 private static class DrawableFadeDisplayer implements BitmapDisplayer { private final int d

hadoop1.0 TaskTracker因为分布式缓存导致内存泄露的一次问题排查

上周五同事到公司说凌晨的时候有值班同事打电话给他,有部分job卡住了,运行了很长时间都没运行完成,由于是凌晨,他没来得及详细的查看日志,简单的把有问题的tasktracker重启了一下,只有一个节点的TaskTracker进程停掉,让我查一下具体是什么问题.以下是排查过程: 1.登陆到停掉TT进程的处理机 (1).查看磁盘空间 磁盘没有出现空间不足的情况. (2).top查看负载和内存使用情况: 根据上图看出内存和负载都不算高,也不存在僵尸进程. 2.查看进程日志 1.log4j日志: 2014

BingMap频繁Add Pushpin和Delete Pushpin会导致内存泄露

最近在做性能测试的时候发现BingMap内存泄露(memory leak)的问题,查找了一些国外的帖子,发现也有类似的问题,但是没有好的解决办法. https://social.msdn.microsoft.com/Forums/en-US/3226f255-2ae1-4718-b848-5f24e76b64b0/your-pushpins-are-broken-addremove-leads-to-memory-leak?forum=bingmapsajax 经过一番尝试,找到了一个折中的解决

Handler导致内存泄露分析

Handler mHandler = new Handler() {    @Override    public void handleMessage(Message msg) {            // do something.    }}```当我们这样创建`Handler`的时候`Android Lint`会提示我们这样一个`warning: In Android, Handler classes should be static or leaks might occur.`. 一

fastjson反序列化使用不当导致内存泄露

分析一个线上内存告警的问题时,发现了造成内存告警的原因是使用fastjson不当导致的. 分析dump发现com.alibaba.fastjson.util.IdentityHashMap$Entry对象比较多. 查找相关文档: fastjson IdentityHashMap 内存泄漏排查 (这篇文档分析描述的情况与我们遇到的问题的原因一样,是使用com.alibaba.fastjson.util.ParameterizedTypeImpl不当导致的) fastjon官方在很早的版本就修复过类

logging 模块误用导致的内存泄露

首先介绍下怎么发现的吧, 线上的项目日志是通过 logging 模块打到 syslog 里, 跑了一段时间后发现 syslog 的 UDP 连接超过了 8W, 没错是 8 W. 主要是 logging 模块用的不对 我们之前有这么一个需求, 就是针对每一个连接日志输出当前连接的信息, 所以每一个 连接就创建了一个日志实例, 并分配一个 Formatter, 创建日志实例为了区分其他连接 所以我就简单粗暴的用了当前对象的 id 来作为日志名称: import logging class Conne

静态变量导致的内存泄露

public  class MainActivity extends Activity{                private static final String TAG = "MainActivity";             private static Context sContext;                   @Override             protected void onCreate(Bundle savedInstanceState)

Android开发编码规范导致的内存泄露问题

在很久很久之前,看过一篇关于内存泄露的文章,里面列举了比较全的应该注意的问题,后来找不到原文地址,今天翻了微博,找到了该文章,为了方便日后自己查看,将注意的问题提取出来.在android开发中,我们的编码习惯可能会让我们编写出一些容易导致内存泄露的代码.所以我们应该要养成一个良好的编码习惯. 单例 平时,我们可能会这样写单例 public class Singleton{ private static Singleton instance; private Context mContext; p