展开

关键词

Visual C++检测工具(VLD)

简述CC++ 程序越复杂,的管理显得越重要,稍有不慎就会出现漏。如果漏不是很严重,在短时间对程序不会有太大影响,这也使得漏问题有很强的隐蔽性,不易被发现。 VLDVLD(Visual Leak Detector)是一款用于 Visual C++ 的免费检测工具。 相比较其它检测工具,它在检测到漏的同时,还具有如下特点:可以得到漏点的调用堆栈,如果可以的话,还能得到其所在文件及行号;可以得到的完整数据;可以设置报告的级别;它是一个已经打包的 报告列出了是在第几块、所在的地址、的字节、调用的堆栈、容。双击调用堆栈可以跳转到所在行。 这也是美中不足的一点,如果使用 Qt,只能先使用 VC++ 编译器捕捉并解决,再考虑使用 mingw(gccg++)编译程序。更多参考VLD

2K70

你踩过几种C++的坑?

在Modern C++之前,C++无疑是个更容易写出坑的语言,无论从开发效率,和易坑性,让很多新手望而却步。 比如问题,就是经常会被写出来的坑,本文就让我们一起来看看,这些让现在或者曾经的C++程序员泪流满面的场景吧。你是否有踩过? 1. 函数或者类成员未释放这类问题可以称之为out of scope的时候,并没有释放相应对象的堆上。有时候最简单的场景,反而是最容易犯错的。这个我想主要是因为经常写,哪有不出错。 上述代码在调用FreeObj的时候,delete看到的是一个void *, 只会释放对象所占用的,但是并不会调用对象的析构函数,那么对象部的m_pStr所指向的并没有被释放,从而会导致 那么在调用delete pObj;会出现吗?class Father{public: virtual void DoSomething(){ std::cout

10420
  • 广告
    关闭

    腾讯云前端性能优化大赛

    首屏耗时优化比拼,赢千元大奖

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    你踩过几种C++的坑?

    在Modern C++之前,C++无疑是个更容易写出坑的语言,无论从开发效率,和易坑性,让很多新手望而却步。 比如问题,就是经常会被写出来的坑,本文就让我们一起来看看,这些让现在或者曾经的C++程序员泪流满面的场景吧。你是否有踩过?1. 函数或者类成员未释放这类问题可以称之为out of scope的时候,并没有释放相应对象的堆上。有时候最简单的场景,反而是最容易犯错的。这个我想主要是因为经常写,哪有不出错。 上述代码在调用FreeObj的时候,delete看到的是一个void *, 只会释放对象所占用的,但是并不会调用对象的析构函数,那么对象部的m_pStr所指向的并没有被释放,从而会导致 那么在调用delete pObj;会出现吗?class Father{public: virtual void DoSomething(){ std::cout

    8950

    微软Debug CRT库是如何追踪C++的?

    本人在之前已经写过四篇关于Windows中如何查找的方法,基本上可以帮你找到的问题所在。 那么为什么要写这篇文章呢?本人在逛知乎的时候,看到一个问题, 不乏很多高手的回答。 我正好也写了几篇通过工具去分析的文章,那先说说工具的方法原理:对的分配的监测: 记录申请时候函数调用栈。 本人正好在上学的时候用过微软 DEBUG CRT库检测过,那就让我们一起再来看看其原理,也正是可以自己去实现的一种方法,要做到知其然知其所以然。微软Debug CRT库检测C++原理? 就是通过在申请的头部记录当前分配的相关信息,比如文件名和行号,并且通过双向链表将所有申请的节点串起来。然后在合适的时间点(比如感知到的情况下)打印出可能的关联的信息。 本文旨在通过分析微软Debug CRT库的实现的检测的方式,从而阐述自我实现简易C++检测的思想。若平时分析问题,建议还是采用本文开头提到的几篇文章的方法。

    8430

    Unix下c程序检测工具

    Valgrind是一款用于调试、漏检测以及性能分析的软件开发工具。  }   编译#gcc -g -o test test.c检查#valgrind --tool=memcheck --leak-check=yes --show-reachable=yes .test 说明 Invalid write of size 4:表示数组越界写了4字节40 bytes in 1 blocks:表示因程序退出而发生40字节修复bug,重新检查提示已经没有? 文档:Valgrind 中包含的 Memcheck 工具可以检查以下的程序错误:   使用未初始化的 (Use of uninitialised memory)  使用已经释放了的 (Readingwriting memory after it has been free’d)  使用超过malloc分配的空间(Readingwriting off the end of malloc’d blocks)

    35870

    C++11】 使用C++11解决--智能指针

    众所周知,C#和java中不需要开发人员自己释放,对象引用计数为零后.Net和Java虚拟机会对对象进行自动回收,从而防止;但是C++语言中,在堆上分配的必须自己去管理,不用的时候要自己释放 ,如果管理不当就可能会出现C++11提供了智能指针,使用智能指针后不需要用户自己释放空间,一旦使用时对象超出了自己的生命周期,就会进行自动释放,从而有效解决了的问题。 1 共享智能指针:std::shared_ptrstd::share_ptr指针的每一个拷贝都指向同一个对象,只有在引用计数为零时才会被释放。

    2710

    应用程序一般使用malloc,calloc,realloc等函数(C++中使用new操作符)从堆中分配到一块,使用完后,程序必须负责相应的调用free或delete释放该块,否则,这块就不能被再次使用 4.的几种常见原因1、对于通过new等运算符申请到的空间在使用之后没有释放掉。 就造成了。    3、对于有的时候是忘记了回收,但是有的时候是无法回收,比如1中提到的析构函数不正确导致,这是属于程序有问题;还有关于面向对象编程的一个的可能性:一个对象在构造函数中抛出异常,对象本身的会被成功释放 是指程序中间动态分配了,但是在程序结束时没有释放这部分,从而造成那一部分不可用的情况,重起计算机可以解决,但是也有可能再次发生和硬件没有关系,它是由软件引起的。

    35780

    排查之线程

    基础(Memory Leak)java中都是由jvm管理,垃圾回收由gc负责,所以一般情况下不会出现问题,所以容易被大家忽略。 有时不严重且不易察觉,这样开发者就不知道,需要自主观察,比较严重的时候,没有可以分配,直接oom。主要和溢出做区分。 这里就不展开了heap比较常见的静态集合类引起监听器:但往往在释放对象的时候却没有记住去删除这些监听器,从而增加了漏的机会。 非静态部类的对象会隐式强引用其外围对象,所以在部类未释放时,外围对象也不会被释放,从而造成漏单例模式:不正确使用单例模式是引起的一个常见问题,单例对象在被初始化后将在JVM的整个生命周期中在 (以静态变量的方式),如果单例对象持有外部对象的引用,那么这个外部对象将不能被jvm正常回收,导致其它第三方类本例(线程)本例现象占用率达80%+左右,并且持续上涨,最高点到94% ?

    83740

    排查之线程

    阅读本文需要5分钟基础(Memory Leak)java中都是由jvm管理,垃圾回收由gc负责,所以一般情况下不会出现问题,所以容易被大家忽略。 有时不严重且不易察觉,这样开发者就不知道,需要自主观察,比较严重的时候,没有可以分配,直接oom。主要和溢出做区分。 这里就不展开了heap比较常见的静态集合类引起监听器:但往往在释放对象的时候却没有记住去删除这些监听器,从而增加了漏的机会。 非静态部类的对象会隐式强引用其外围对象,所以在部类未释放时,外围对象也不会被释放,从而造成漏单例模式:不正确使用单例模式是引起的一个常见问题,单例对象在被初始化后将在JVM的整个生命周期中在 (以静态变量的方式),如果单例对象持有外部对象的引用,那么这个外部对象将不能被jvm正常回收,导致其它第三方类本例(线程)本例现象占用率达80%+左右,并且持续上涨,最高点到94% ?

    50610

    溢出和

    memory leak,是指程序在申请后,无法释放已申请的空间,一次危害可以忽略,但堆积后果很严重,无论多少,迟早会被占光。 就是分配的不足以放下数据项序列,称为溢出. 以发生的方式来分类,漏可以分为4类: 1. 常发性漏。发生漏的代码会被多次执行到,每次被执行的时候都会导致一块漏。 2. 一次性漏。发生漏的代码只会被执行一次,或者由于算法上的缺陷,导致总会有一块仅且一块发生漏。比如,在类的构造函数中分配,在析构函数中却没有释放该,所以漏只会发生一次。 隐式漏。程序在运行过程中不停的分配,但是直到结束的时候才释放。严格的说这里并没有发生漏,因为最终程序释放了所有申请的。 从用户使用程序的角度来看,漏本身不会产生什么危害,作为一般的用户,根本感觉不到漏的在。真正有危害的是漏的堆积,这会最终消耗尽系统所有的

    72810

    C++栈展开如何防止

    在栈展开(stack unwinding)是指,如果在一个函数部抛出异常,而此异常并未在该函数部被捕捉,就将导致该函数的运行在抛出异常处结束,所有已经分配在栈上的局部变量都要被释放。 如果被释放的变量中有指针,而该指针在此前已经用new运算申请了空间,就有可能导致。因为栈展开的时候并不会自动对指针变量执行delete(或delete[])操作。 因此,在有可能发生异常的函数中,可以利用“智能指针”auto_ptr来防止。参考如下程序。

    23010

    C++栈展开如何防止

    在栈展开(stack unwinding)是指,如果在一个函数部抛出异常,而此异常并未在该函数部被捕捉,就将导致该函数的运行在抛出异常处结束,所有已经分配在栈上的局部变量都要被释放。 如果被释放的变量中有指针,而该指针在此前已经用new运算申请了空间,就有可能导致。因为栈展开的时候并不会自动对指针变量执行delete(或delete[])操作。 因此,在有可能发生异常的函数中,可以利用“智能指针”unique_ptr来防止。参考如下程序。

    45930

    Dockerd资源系列 - &FD - 1

    live-restore,然后重启dockerd,而不影响正常运行的容器,但是重启后还一直的问题。 可以总结为两类情况:没有设置live-restore: true的和设置了live-restore: true且重启过dockerd的,这里是针对后者的排查,因为线上默认dockerd没有开启debug dockerd日志 tail -f varlogmessages | grep dockerd,结果如下图,的dockerd的日志都有如下的日志记录,且看时间规律是相同sandbox的记录每秒打印一遍 不关注源码的可以直接跳过源码,直接看代码的解释pprof分析开启dockerd的debug模式,即编辑etcdockerdaemon.json,加上debug: true的配置并重启dockerd,方便利用pprof来定位对应的代码位置 的api,最终调用SubscribeTopic,此函数里面

    30220

    IE中的

    参考文章: Winter 的《浏览器中的》 鸟食轩的《理解并解决IE的方式》IBM的《JavaScript中的模式》还有两篇文章:IEs memory-leak fix greatly exaggeratedMemory Leakage in Internet Explorer – revisitedIE中的几种方式:1、循环引用(Circular References) — 为了演示这个问题,我们将通过重写Script元素中的容来引发大量漏。循环引用:? 但确实发生,为什么,因为有onclick=foo()何以证明? 虽然IE有这么多的问题,但还是有工具可以检测你写的代码是否,对于代码量少、复杂度并不高的可以使用sIEve,大项目中使用它想跟踪产生的代码则比较困难了。

    30840

    【翻译】JavaScript

    造成这个问题的罪魁祸首就是memory leak()。下面我们将讨论一下的管理以及最常见的问题。 指的是浏览器因为种种原因没有回收无用对象占用的的原因可能是浏览器的bug,或者浏览器扩展插件的问题,但是更多的时候,是因为我们代码结构的不严谨。 对于服务器端的JS和V8引擎关于setInterval的问题可以参考:Memory leak when running setInterval in a new context的占用空间简单的数据结构引起的所占用的空间很少 jQuery处理方法及其弊端jQuery用$.data方法处理IE6-7的,不幸的是,与此同时也引起了jQuery专属的问题。 检查jQuery的非常简单,查看$.cache可以很方便的找出问题的引发原因。jQuery的问题讨论到此为止。找出并修复问题找出问题的方式有很多,浏览器也不断有新的bug出现。

    53260

    实战Go

    关于Go的有这么一句话不知道你听过没有:10次,有9次是goroutine。 我所解决的问题,也是goroutine导致的,所以这篇文章主要介绍Go程序的goroutine,掌握了如何定位和解决goroutine,就掌握了的大部分场景。 heap“不能”定位goroutine怎么导致什么是goroutinegoroutine怎么导致怎么确定是goroutine引发的定位goroutine的 ,只是发现跟某种场景有关,根本找不到的根源,如果哪位朋友用heap就能定位的线上问题,麻烦介绍下。 如第一条所言,能通过heap找到占用多的位置,但这个位置通常不一定是,就算是,也只是的结果,并不是真正导致的根源。

    1.6K10

    skywalking排查

    背景介绍最近写的关于dubbo稍微复杂了一点,很多人表示看不明白,想到之前遇到的比较简单的问题,更容易入门,于是拿出来分享一下。 GC保证了dump出来里的对象都是活的(无法释放)。 线索难以查出真相,很多时候就是这样,问题从本身只能分析出一点线索,不足以找出真相,除非它是个非常简单的问题。 以经验来看,问题都会伴随着cpu升高,因为不够使用触发full GC,但full GC又无法释放,恶性循环,所以一开始并没有去看cpu的问题。 总结问题伴随着cpu,错误率,GC频繁等问题最重要的是拿到现场dump文件,并用工具结合源码分析如果第二条解决不了问题,则需要寻找新的突破口,比如jstack等

    1.1K20

    Java分析

    Java虽然有垃圾回收机制,但是也可能会因为对象被无意引用,导致没有释放,占用了太多。 常见的有全局集合类 堆对象统计信息命令:jmap -histo:live pid 描述:显示堆中对象的统计信息可以看到各个类的实例数和占用大小 num #instances #bytes class name---------------------------------------------- 1: 699830 601799480 描述:生成堆转储快照dump文件 dump镜像,我们就可以使用分析工具 (MAT),查看各个类的引用链路,找到漏点 使用MAT分析 一般使用Dominator Tree,因为一般对象的占用大小只是该对象本身的大小,不包含其引用其他对象的大小,Dominator Tree 可以计算对象以及被其引用的其他对象的大小,这样就可以找到最终导致的点从MAT分析结果来看: ch.qos.logback.classic.LoggerContext父类ContextBase中的

    6810

    Android context(ApplicationActivity)与

    但是这样如果context发生的话,就会很多,这里的意思是gc没有办法回收activity的(当前Activity为活动或finish后还没来得及回收)。 实现这个要求的简单想法就是定义一个静态的Drawable,这样Activity 类创建销毁它始终保中,访问速度会很快。  既然drawable不能销毁,它所引用和间接引用的都不能销毁,这样系统就没有办法销毁当前的activity,于是造成了。gc对这种类型的是无能为力的。  避免这种的方法是避免activity中的任何对象的生命周期长过activity,避免由于对象对 activity的引用导致activity不能正常被销毁同时,我们可以使用application 使用Application,需要在 AndroidManifest.xml 文件注册,即android:name=.GApplication: 避免context相关的,记住以下几点: 1.

    48520

    的一些坑

    Activity部类漏Activity如果部类,无论是匿名部类,或者是声明的部类,都有可能造成Activity漏,因为部类默认是直接持有这个activity的引用,如果部类的生命周期比 activity的生命周期要长,那么在activity销毁的时候部类仍然在并且持有activity的引用,那么activity自然无法被gc,造成漏Activity部Handlerclass 漏就不在了动画导致漏进入Activity界面后如果有一些和控件绑定在一起的属性动画在运行,退出的时候要记得cancel掉这些动画自定义控件ImageButton中:public void 控件的BackGround导致的漏(4.0android系统已经解决)有时候为了避免图片反复的加载,就把第一次加载后的Bitmap或者Drawable用静态变量保起来,但是要是把这种静态修饰的图片对象设置成控件的背景 ,不过在4.0系统以后引入回调来保View对象了,所以已经不会造成漏问题了:public final void setCallback(Callback cb) { mCallback = new

    93820

    相关产品

    • 消息队列 TDMQ

      消息队列 TDMQ

      消息队列 TDMQ 是基于 Apache 顶级开源项目Pulsar自研的金融级分布式消息中间件,是一款具备跨城高一致、高可靠、高并发的分布式消息队列,拥有原生Java 、 C++、Python、GO 多种API, 支持 HTTP 协议方式接入,可为分布式应用系统提供异步解耦和削峰填谷的能力,同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。

    相关资讯

    热门标签

    活动推荐

      运营活动

      活动名称
      广告关闭

      扫码关注云+社区

      领取腾讯云代金券