BetterCV
BetterCV

内存泄漏检测工具Valgrind与OpenCV搭配使用

内存泄漏的含义

关于”内存泄漏“，有两种定义：

  1. 程序结束时，有指针变量ptr能访问到申请的堆内存，但没通过free(ptr)来释放。即“程序结束时知道它在哪里，但确实没释放它”。

  2. 程序结束时，之前申请的堆内存无法被任何一个指针变量访问，导致无法访问这块堆内存空间，造成了泄漏。也就是“程序结束时不知道它在哪里，也就没办法释放它”。

Valgrind的Memcheck工具，融合了上述两种类型的定义，并细分为如下5种：

编号 内存泄漏类型 具体含义 说明
1 definitely lost 很明显的内存泄漏 必须修复
2 indirectly lost 程序的一个基于指针的结构里存在内存泄漏 必须修复
3 possibly lost 全局或静态指针指向堆内存，指针往后偏移但仍在该内存内，并最终free 必须修复
4 still reachable 全局或静态指针指向堆内存，最终没有free这块内存 通常不严重，可以不管
5 suppressed 被抑制的内存错误，基于传入的suppressed文件 通常是配置忽略第三方库的内存泄漏

容易想到，让OpenCV搭配Valgrind，检查和报告其内存泄漏：

valgrind-opencv.png

我遇到的情况是OpenCV有内存泄漏，通过传入opencv.supp文件可以抑制它产生的possibly lost内存错误（放到了suppressed类型中），still reachable错误则忽略不管。生成和使用opencv.supp文件：

valgrind --gen-suppressions=all --leak-check=yes ./a.out 2>&1 | tee valgrind.out

sed '/==/ d' valgrind.out > opencv.supp

valgrind --leak-check=yes --suppressions=opencv.supp ./a.out

以下是探索（罗嗦）版本的内容：

Valgrind基本介绍

在Linux下用Valgrind检查自己代码的内存泄漏情况。Valgrind是一组工具的集合，其中最基本的、并且是默认的工具，是Memcheck，可以检查内存泄漏情况。

Valgrind是一组工具的集合：

  1. Memcheck：内存错误检查器。最主要的、默认的工具（不需要指定--tool=memcheck就会使用的）
  2. 其他工具：Cachegrind / Callgrind / Helgrind / DTR / Massif / DHAT / SGcheck / BBV / ...，这些工具需要用--tool=xxx参数指定后才能使用

Valgrind支持的平台有很多：

X86/Linux, AMD64/Linux, ARM/Linux, ARM64/Linux, PPC32/Linux, PPC64/Linux, PPC64LE/Linux, S390/Linux, MIPS32/Linux, MIPS64/Linux, X86/Solaris, AMD64/Solaris, ARM/Android(2.3.x and later), ARM64/Android, X86/Android(4.0 and later), MIPS32/Android, X86/Darwin, AMD64/Darwin

使用Valgrind的Memcheck工具，基本步骤

  1. 编写自己的程序；
vim xxx.c
  1. 使用-g参数编译程序，用来提供行号信息、符号表等；
gcc xxx.c -g
  1. 使用valgrind调用第2步编译出的可执行程序，建议添加--leak-check=yes参数来获取详细信息
valgrind --leak-check=yes ./a.out [arg1, arg2, ...]

其中[arg1, arg2, ...]表示可选参数

Valgrind的输出格式简要说明

比如我的测试代码是：

#include 

void f(void)
{
    int* x = malloc(10 * sizeof(int));
    x[10] = 0;        // problem 1: heap block overrun(越界)
}                    // problem 2: memory leak -- x not freed（内存泄漏）

int main(void)
{
    f();
    return 0;
}

对应的Valgrind输出为：

==5738== Invalid write of size 4
==5738== at 0x400544: f (test.c:6)
==5738== by 0x400555: main (test.c:11)
==5738== Address 0x5204068 is 0 bytes after a block of size 40 alloc'd
==5738== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5738== by 0x400537: f (test.c:5)
==5738== by 0x400555: main (test.c:11)

说明：

  • 每条错误信息中都有很多细节，仔细看
  • 5738是进程编号(pid)，通常来说不重要
  • 第一行（"Invalid write...") 表明了错误类型。这里的情况是，写到申请的堆内存(heap block)之外了，也就是越界。
  • 接下来的几行是栈记录(stack trace)，表明了问题出在哪里。栈记录可能会很多，甚至让人看得头疼，尤其是当你用了C++ STL的时候。这些信息从下往上看会好一点。如果栈记录不大，可以使用--num-callers参数让它多数出东西。
  • 代码地址（比如0x400544)通常来说不重要，但有时候对于跟踪诡异的bug来说很重要。
  • 一些重要的错误信息有第二个组件，描述了相关的内存地址。在这个例子中显示的是，被写的内存地址刚刚超过了代码中第5行malloc()分配的内存块的最后面。

通常是从最前面的错误开始修复，因为后面的出错很可能是前面的错误导致的。不然的化你会觉得Memcheck很难用。

Valgrind的Memcheck工具的内存泄漏错误类型举例

在valgrind的输出内容中，找到LEAK SUMMARY字段，它下面汇总了各种类型的内存泄漏：

内存泄漏细分类型 含义
definitely lost 确信无疑的内存泄漏
indirectly lost 间接的内存泄漏
possibly lost 可能有内存泄漏
still reachable 程序退出时仍然可以访问的内存，也是泄漏
suppressed 被抑制的

（表格参考：Valgrind笔记(一)——Memcheck初探 )

在我这样一个小白看来，细分成这么多类型的内存泄漏，我其实不是很分得清楚各自的区别。能否举例说明呢？经过一番搜索，基于这篇博客：valgrind 所报的4种内存丢失到底是什么意思(简洁)，我拆分和修改出以上4种类型的内存泄漏各自的例子，根据例子更容易理解。

例子0：definitely lost

definitely lost意思是：确信无疑的内存泄漏，缺少free/detelete/delete[]操作。
举例：

#include 
#include 

int main()
{
    float* data = (float*)malloc(sizeof(float)*5);

    return 0;
}

gcc example2.c -g 
valgrind --leak-check=yes ./a.out

==23257== Memcheck, a memory error detector
==23257== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==23257== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==23257== Command: ./a.out
==23257==
==23257==
==23257== HEAP SUMMARY:
==23257== in use at exit: 20 bytes in 1 blocks
==23257== total heap usage: 1 allocs, 0 frees, 20 bytes allocated
==23257==
==23257== 20 bytes in 1 blocks are definitely lost in loss record 1 of 1
==23257== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23257== by 0x400577: main (example2.c:6)
==23257==
==23257== LEAK SUMMARY:
==23257== definitely lost: 20 bytes in 1 blocks
==23257== indirectly lost: 0 bytes in 0 blocks
==23257== possibly lost: 0 bytes in 0 blocks
==23257== still reachable: 0 bytes in 0 blocks
==23257== suppressed: 0 bytes in 0 blocks
==23257==
==23257== For counts of detected and suppressed errors, rerun with: -v
==23257== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

例子1：indirectly lost

indirectly lost，说的很玄乎，还是看例子比较直观：

#include 
#include 

typedef struct Image {
    int h, w, c;
    float* data;
} Image;

int main()
{
    Image* im = (Image*)malloc(sizeof(Image));
    int h = 224, w = 224, c = 3;
    im->h = h;
    im->w = w;
    im->c = c;
    im->data = (float*)malloc(sizeof(float)*h*w*c);

    return 0;
}

gcc example2.c -g
valgrind --leak-check=yes ./a.out

==23580== Memcheck, a memory error detector
==23580== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==23580== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==23580== Command: ./a.out
==23580==
==23580==
==23580== HEAP SUMMARY:
==23580== in use at exit: 602,136 bytes in 2 blocks
==23580== total heap usage: 2 allocs, 0 frees, 602,136 bytes allocated
==23580==
==23580== 602,136 (24 direct, 602,112 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 2
==23580== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23580== by 0x400537: main (example2.c:11)
==23580==
==23580== LEAK SUMMARY:
==23580== definitely lost: 24 bytes in 1 blocks
==23580== indirectly lost: 602,112 bytes in 1 blocks
==23580== possibly lost: 0 bytes in 0 blocks
==23580== still reachable: 0 bytes in 0 blocks
==23580== suppressed: 0 bytes in 0 blocks
==23580==
==23580== For counts of detected and suppressed errors, rerun with: -v
==23580== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

样例代码中，缺少的是：

free(im->data);
free(im);

因为没有free(im)，因此im对应的内存泄漏了；而im对应的内存块里面，有一个data字段，data字段现在也没有被释放，因此，602,112字节说的是224*224*4*sizeof(float)这么一大块内存是indirectly lost。需要注意的是，definitely lost此时为24字节，如果调用了free(im)也就是消除了当前的definitely lost，则当前的indirectly lost会升级为definitely lost。

例子2：possibly lost

找到possibly lost的例子并不很容易。按官方说法是，指针指向malloc申请的内存，然后指针往后++，再free这个指针，就得到possibly lost。看看下面这两个例子，按照这个解释，其实分别得到possibly lost和definitely lost。

possibly lost:

#include 
#include 

int* g_p1;

void fun()
{
    g_p1 = (int*)malloc(sizeof(int)*10);
    g_p1++;
}

int main()
{
    fun();
    free(g_p1);

    return 0;
}

==24652== Memcheck, a memory error detector
==24652== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24652== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24652== Command: ./a.out
==24652==
==24652== Invalid free() / delete / delete[] / realloc()
==24652== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24652== by 0x4005AC: main (example2.c:15)
==24652== Address 0x5204044 is 4 bytes inside a block of size 40 alloc'd
==24652== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24652== by 0x400573: fun (example2.c:8)
==24652== by 0x40059D: main (example2.c:14)
==24652==
==24652==
==24652== HEAP SUMMARY:
==24652== in use at exit: 40 bytes in 1 blocks
==24652== total heap usage: 1 allocs, 1 frees, 40 bytes allocated
==24652==
==24652== 40 bytes in 1 blocks are possibly lost in loss record 1 of 1
==24652== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24652== by 0x400573: fun (example2.c:8)
==24652== by 0x40059D: main (example2.c:14)
==24652==
==24652== LEAK SUMMARY:
==24652== definitely lost: 0 bytes in 0 blocks
==24652== indirectly lost: 0 bytes in 0 blocks
==24652== possibly lost: 40 bytes in 1 blocks
==24652== still reachable: 0 bytes in 0 blocks
==24652== suppressed: 0 bytes in 0 blocks
==24652==
==24652== For counts of detected and suppressed errors, rerun with: -v
==24652== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

definitely lost:

#include 
#include 

int main()
{
    int* p1 = (int*)malloc(sizeof(int)*10);
    p1++;
    free(p1);

    return 0;
}

==24703== Memcheck, a memory error detector
==24703== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24703== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24703== Command: ./a.out
==24703==
==24703== Invalid free() / delete / delete[] / realloc()
==24703== at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24703== by 0x40058C: main (example22.c:8)
==24703== Address 0x5204044 is 4 bytes inside a block of size 40 alloc'd
==24703== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24703== by 0x400577: main (example22.c:6)
==24703==
==24703==
==24703== HEAP SUMMARY:
==24703== in use at exit: 40 bytes in 1 blocks
==24703== total heap usage: 1 allocs, 1 frees, 40 bytes allocated
==24703==
==24703== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==24703== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24703== by 0x400577: main (example22.c:6)
==24703==
==24703== LEAK SUMMARY:
==24703== definitely lost: 40 bytes in 1 blocks
==24703== indirectly lost: 0 bytes in 0 blocks
==24703== possibly lost: 0 bytes in 0 blocks
==24703== still reachable: 0 bytes in 0 blocks
==24703== suppressed: 0 bytes in 0 blocks
==24703==
==24703== For counts of detected and suppressed errors, rerun with: -v
==24703== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

例子3：still reachable

和例子2类似，still reacheable类型的内存泄漏，和definitely lost类型的内存泄漏，我觉得仍然是一个是全局变量的指针、另一个是局部变量指针的区别。来看例子：

still reachable

#include 
#include 

int* g_p1;

void fun()
{
    g_p1 = (int*)malloc(sizeof(int)*10);
}

int main()
{
    fun();

    return 0;
}

==24892== Memcheck, a memory error detector
==24892== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24892== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24892== Command: ./a.out
==24892==
==24892==
==24892== HEAP SUMMARY:
==24892== in use at exit: 40 bytes in 1 blocks
==24892== total heap usage: 1 allocs, 0 frees, 40 bytes allocated
==24892==
==24892== LEAK SUMMARY:
==24892== definitely lost: 0 bytes in 0 blocks
==24892== indirectly lost: 0 bytes in 0 blocks
==24892== possibly lost: 0 bytes in 0 blocks
==24892== still reachable: 40 bytes in 1 blocks
==24892== suppressed: 0 bytes in 0 blocks
==24892== Reachable blocks (those to which a pointer was found) are not shown.
==24892== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==24892==
==24892== For counts of detected and suppressed errors, rerun with: -v
==24892== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

definitely lost
其实这个例子就是“例子0：definitely lost”的例子，2333：

#include 
#include 

int main()
{
    int* g_p1 = (int*)malloc(sizeof(int)*10);

    return 0;
}

==24984== Memcheck, a memory error detector
==24984== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24984== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24984== Command: ./a.out
==24984==
==24984==
==24984== HEAP SUMMARY:
==24984== in use at exit: 40 bytes in 1 blocks
==24984== total heap usage: 1 allocs, 0 frees, 40 bytes allocated
==24984==
==24984== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==24984== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24984== by 0x400537: main (example33.c:6)
==24984==
==24984== LEAK SUMMARY:
==24984== definitely lost: 40 bytes in 1 blocks
==24984== indirectly lost: 0 bytes in 0 blocks
==24984== possibly lost: 0 bytes in 0 blocks
==24984== still reachable: 0 bytes in 0 blocks
==24984== suppressed: 0 bytes in 0 blocks
==24984==
==24984== For counts of detected and suppressed errors, rerun with: -v
==24984== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

简要总结Memcheck的内存泄漏类型

  1. definitely lost: 局部变量，用了malloc/calloc申请的堆内存，没有释放
  2. indirectly lost: 某个局部变量结构体对象本身是从malloc/calloc申请的堆内存，没有释放；并且，这个结构体的某个成员是个指针，也是用malloc/calloc从堆上申请的内存，也没有释放。此时，这个成员指向的内存，是indirectly lost。如果这个结构体对象被释放了，那么这个成员指向的内存，就是definitely lost。
  3. possibly lost：全局变量，指针类型，在某个函数中用malloc/calloc申请了堆内存给它，然后指针往后偏移了一部分，但是仍然处于这块堆内存里面，并且最后free了这个指针。那么这是possibly lost。
  4. still reachable：全局变量，指针类型，在某个函数中用malloc/calloc申请了堆内存给它，并且这个指针没有偏移；但是呢，最终程序没有free掉这个指针。这就是still reachable。

不管是以上哪种类型的内存泄漏，最理想最安全的做法都应该是，修复其中每种错误，确保没有内存泄漏。然而事实上也许并不容易，因为一旦你的程序用了第三方库，而这个第三方库有内存泄漏，那就需要搞清楚是谁写了bug。典型的例子是OpenCV。

OpenCV内存泄漏，例子1

测试环境：ubuntu16.04

opencv版本：sudo apt install libopencv-dev，2.4.9

#include 
#include 

#include 
#include 

int main()
{
    const char* filename = "cat.jpg";
    IplImage* im = cvLoadImage(filename, -1);
    cvReleaseImage(&im);

    return 0;
}

Makefile:

CC=clang-3.5
OPENCV=opencv #apt-get's opencv
#OPENCV=/usr/local/opencv-4.1.1/lib/pkgconfig/opencv4.pc

#CFLAGS=-Wall `pkg-config --cflags $(OPENCV)` -O3 -flto -ffast-math
CFLAGS=-Wall `pkg-config --cflags $(OPENCV)` -O0 -g
LDFLAGS=`pkg-config --libs $(OPENCV)` -lm
#VPATH=./src/

OBJ=example4.o

all: a.out

a.out: $(OBJ)
    $(CC) $(CFLAGS) $^ $(LDFLAGS) -o $@

%.o: %.c
    $(CC) $(CFLAGS) -c $< -o $@

.PHONY: clean

clean:
    rm -rf $(OBJ) a.out

编译运行：如果开启--leak-check=yes，输出内容特别多，这里没有开启

make
valgrind ./a.out

输出：

==26429== Memcheck, a memory error detector
==26429== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==26429== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==26429== Command: ./a.out
==26429==
==26429==
==26429== HEAP SUMMARY:
==26429== in use at exit: 228,088 bytes in 931 blocks
==26429== total heap usage: 4,282 allocs, 3,351 frees, 2,267,105 bytes allocated
==26429==
==26429== LEAK SUMMARY:
==26429== definitely lost: 0 bytes in 0 blocks
==26429== indirectly lost: 0 bytes in 0 blocks
==26429== possibly lost: 1,352 bytes in 18 blocks
==26429== still reachable: 226,736 bytes in 913 blocks
==26429== of which reachable via heuristic:
==26429== newarray : 1,536 bytes in 16 blocks
==26429== suppressed: 0 bytes in 0 blocks
==26429== Rerun with --leak-check=full to see details of leaked memory
==26429==
==26429== For counts of detected and suppressed errors, rerun with: -v
==26429== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

看到以上输出中的"possibly lost"和"still reachable"后，显然是OpenCV源码中有内存泄漏，至于在哪里并不清楚。

尝试切换opencv版本，从2.4.9切换到自行编译的3.4.5，依然是上述代码，valgrind输出为：

==27765== Memcheck, a memory error detector
==27765== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==27765== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==27765== Command: ./a.out
==27765==
./a.out: error while loading shared libraries: libopencv_dnn.so.3.4: cannot open shared object file: No such file or directory
==27765== Jump to the invalid address stated on the next line
==27765== at 0x566: ???
==27765== by 0x401044C: _dl_signal_error (dl-error.c:125)
==27765== by 0x400F069: _dl_map_object_deps (dl-deps.c:686)
==27765== by 0x4003A28: dl_main (rtld.c:1647)
==27765== by 0x40198AC: _dl_sysdep_start (dl-sysdep.c:249)
==27765== by 0x4001C29: _dl_start_final (rtld.c:323)
==27765== by 0x4001C29: _dl_start (rtld.c:429)
==27765== by 0x4000C37: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==27765== Address 0x566 is not stack'd, malloc'd or (recently) free'd
==27765==
==27765==
==27765== Process terminating with default action of signal 11 (SIGSEGV)
==27765== Bad permissions for mapped region at address 0x566
==27765== at 0x566: ???
==27765== by 0x401044C: _dl_signal_error (dl-error.c:125)
==27765== by 0x400F069: _dl_map_object_deps (dl-deps.c:686)
==27765== by 0x4003A28: dl_main (rtld.c:1647)
==27765== by 0x40198AC: _dl_sysdep_start (dl-sysdep.c:249)
==27765== by 0x4001C29: _dl_start_final (rtld.c:323)
==27765== by 0x4001C29: _dl_start (rtld.c:429)
==27765== by 0x4000C37: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==27765==
==27765== HEAP SUMMARY:
==27765== in use at exit: 0 bytes in 0 blocks
==27765== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==27765==
==27765== All heap blocks were freed -- no leaks are possible
==27765==
==27765== For counts of detected and suppressed errors, rerun with: -v
==27765== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

看起来，opencv3.4.5相比于opencv2.4.9，减少一些内存泄漏呀。

OpenCV内存泄漏，例子2

这次的例子，不仅仅读取和释放图像，还show图像（基于opencv3.4.5)：

#include 
#include 

#include 
#include 

int main()
{
    const char* filename = "cat.jpg";
    IplImage* im = cvLoadImage(filename, -1);
    cvShowImage("cat", im);
    cvReleaseImage(&im);
    cvWaitKey(0);

    return 0;
}

valgrind输出：

==28062== Memcheck, a memory error detector
==28062== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==28062== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==28062== Command: ./a.out
==28062==
==28062==
==28062== HEAP SUMMARY:
==28062== in use at exit: 1,726,832 bytes in 16,877 blocks
==28062== total heap usage: 100,861 allocs, 83,984 frees, 8,410,822 bytes allocated
==28062==
==28062== LEAK SUMMARY:
==28062== definitely lost: 0 bytes in 0 blocks
==28062== indirectly lost: 0 bytes in 0 blocks
==28062== possibly lost: 4,740 bytes in 50 blocks
==28062== still reachable: 1,631,380 bytes in 16,084 blocks
==28062== of which reachable via heuristic:
==28062== length64 : 5,376 bytes in 87 blocks
==28062== newarray : 2,096 bytes in 51 blocks
==28062== suppressed: 0 bytes in 0 blocks
==28062== Rerun with --leak-check=full to see details of leaked memory
==28062==
==28062== For counts of detected and suppressed errors, rerun with: -v
==28062== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

看到如上输出，看来OpenCV的内存泄漏问题还是没有完全解决。

配置Valgrind，忽略OpenCV的内存泄漏

不得不说，自行去翻看Valgrind中配置memcheck的suppression的文档感觉很繁琐...懒人做法是，让valgrind自己输出需要supprress的每一个配置，重定向到文件，然后去掉额外没用的打印输出内容，保存为opencv-3.4.5.supp文件，下次给valgrind用，就可以忽略opencv的内存泄漏了。

#输出内存错误检测结果，并夹带suppression的配置一并输出；重定向到文件
valgrind --gen-suppressions=all --leak-check=yes ./a.out 2>&1 | tee valgrind.out

#去除文件中不必要的信息，并重定向到新的文件中
sed '/==/ d' valgrind.out > opencv-3.4.5.supp

(参考：Ignore part of code with valgrind - memcheck)

对应的代码：（没错，代码里仅仅是include了opencv，别的啥都没做，但是valgrind就是能检测到内存泄漏）：

#include 
#include 

#include 
#include 

int main()
{

    return 0;
}

没有配置suppression文件的valgrind输出：

valgrind --leak-check=yes ./a.out

==6715== LEAK SUMMARY:
==6715== definitely lost: 0 bytes in 0 blocks
==6715== indirectly lost: 0 bytes in 0 blocks
==6715== possibly lost: 1,352 bytes in 18 blocks
==6715== still reachable: 237,176 bytes in 1,206 blocks
==6715== of which reachable via heuristic:
==6715== newarray : 1,536 bytes in 16 blocks
==6715== suppressed: 0 bytes in 0 blocks
==6715== Reachable blocks (those to which a pointer was found) are not shown.
==6715== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6715==
==6715== For counts of detected and suppressed errors, rerun with: -v
==6715== ERROR SUMMARY: 18 errors from 18 contexts (suppressed: 0 from 0)

配置了suppression的valgrind输出：

valgrind --leak-check=yes --suppressions=opencv-3.4.5.supp ./a.out

==6746== HEAP SUMMARY:
==6746== in use at exit: 238,528 bytes in 1,224 blocks
==6746== total heap usage: 6,218 allocs, 4,994 frees, 666,594 bytes allocated
==6746==
==6746== LEAK SUMMARY:
==6746== definitely lost: 0 bytes in 0 blocks
==6746== indirectly lost: 0 bytes in 0 blocks
==6746== possibly lost: 0 bytes in 0 blocks
==6746== still reachable: 237,176 bytes in 1,206 blocks
==6746== of which reachable via heuristic:
==6746== newarray : 1,536 bytes in 16 blocks
==6746== suppressed: 1,352 bytes in 18 blocks
==6746== Reachable blocks (those to which a pointer was found) are not shown.
==6746== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6746==
==6746== For counts of detected and suppressed errors, rerun with: -v
==6746== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 18 from 18)

没错，possibily lost从1352字节减少到0字节，总算把一部分内存泄漏的锅甩给OpenCV了！当然，still reachable没啥变化。。

这里贴一下我导出的opencv的suppression配置文件的内容（opencv-3.4.5.supp):

{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:realloc
   fun:g_realloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:realloc
   fun:g_realloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:realloc
   fun:g_realloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:realloc
   fun:g_realloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:g_malloc
   fun:g_slice_alloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_add_interface_static
   fun:gtk_button_get_type
   fun:gtk_toggle_button_get_type
   fun:gtk_module_init
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:g_malloc
   fun:g_slice_alloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_add_interface_static
   fun:gtk_icon_view_get_type
   fun:gtk_module_init
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:g_malloc
   fun:g_slice_alloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_add_interface_static
   fun:gtk_icon_view_get_type
   fun:gtk_module_init
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   fun:g_type_class_ref
   fun:g_type_class_ref
   fun:g_param_spec_flags
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   fun:g_type_class_ref
   fun:gtk_module_init
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   fun:g_closure_invoke
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_signal_emit_valist
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   fun:g_type_class_ref
   fun:g_type_class_ref
   fun:g_param_spec_enum
   obj:/usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1800.9
   fun:g_type_class_ref
   fun:g_type_class_ref
   fun:g_object_new_valist
   fun:g_object_new
   obj:/usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1800.9
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:g_malloc
   fun:g_slice_alloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_add_interface_static
   fun:gtk_button_get_type
   fun:gtk_toggle_button_get_type
   fun:gtk_module_init
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:realloc
   fun:g_realloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_static
   fun:g_flags_register_static
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   fun:g_type_class_ref
   fun:g_object_new_valist
   fun:g_object_new
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   fun:g_type_class_ref
   fun:g_type_class_ref
   fun:g_type_create_instance
   fun:g_param_spec_internal
   fun:g_param_spec_object
   obj:/usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1800.9
   fun:g_type_class_ref
   fun:g_object_newv
   fun:g_object_new
   fun:gdk_display_manager_get
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:g_malloc
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_object_new_valist
   fun:g_object_new
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:g_malloc0
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_fundamental
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:g_malloc
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_object_new_valist
   fun:g_object_new
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:realloc
   fun:g_realloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_static
   fun:g_param_type_register_static
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:call_init.part.0
   fun:call_init
   fun:_dl_init
   obj:/lib/x86_64-linux-gnu/ld-2.23.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:g_malloc
   fun:g_memdup
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   fun:gtk_style_context_set_state
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_object_new_valist
   fun:g_object_new
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:g_malloc
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_object_new_valist
   fun:g_object_new
   obj:/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.9
   fun:gtk_style_new
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:realloc
   fun:g_realloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_static
   fun:g_enum_register_static
   fun:atk_state_type_get_type
   fun:atk_state_type_get_name
   fun:atk_object_notify_state_change
   fun:gtk_accessible_set_widget
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_object_new_valist
   fun:g_object_new
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:allocate_dtv
   fun:_dl_allocate_tls
   fun:allocate_stack
   fun:pthread_create@@GLIBC_2.2.5
   obj:/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2
   obj:/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2
   fun:g_thread_new
   obj:/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
   obj:/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
   obj:/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_object_new_valist
   fun:g_object_new
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:allocate_dtv
   fun:_dl_allocate_tls
   fun:allocate_stack
   fun:pthread_create@@GLIBC_2.2.5
   obj:/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2
   obj:/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2
   fun:g_thread_new
   obj:/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2
   fun:g_task_get_type
   obj:/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4800.2
   fun:g_bus_get_sync
   obj:/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:allocate_dtv
   fun:_dl_allocate_tls
   fun:allocate_stack
   fun:pthread_create@@GLIBC_2.2.5
   obj:/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2
   obj:/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2
   fun:g_thread_new
   obj:/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4800.2
   obj:/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4800.2
   fun:g_bus_get_sync
   obj:/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
   obj:/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
   fun:g_main_context_dispatch
}
{
   
   Memcheck:Leak
   match-leak-kinds: possible
   fun:realloc
   fun:g_realloc
   obj:/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.2
   fun:g_type_register_static
   fun:g_type_register_static_simple
   fun:gtk_window_group_get_type
   fun:gtk_window_group_new
   fun:gtk_window_get_group
   fun:gtk_main_do_event
   obj:/usr/lib/x86_64-linux-gnu/libgdk-3.so.0.1800.9
   fun:g_main_context_dispatch
   obj:/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2
}

那么，still reachable到底什么意思呢？

参考http://shigaro.org/2019/07/05/valgrind-2/#，

There is more than one way to define “memory leak”. In particular, there are two primary definitions of “memory leak” that are in common usage among programmers.

The first commonly used definition of “memory leak” is, “Memory was allocated and was not subsequently freed before the program terminated.” However, many programmers (rightly) argue that certain types of memory leaks that fit this definition don’t actually pose any sort of problem, and therefore should not be considered true “memory leaks”.

An arguably stricter (and more useful) definition of “memory leak” is, “Memory was allocated and cannot be subsequently freed because the program no longer has any pointers to the allocated memory block.” In other words, you cannot free memory that you no longer have any pointers to. Such memory is therefore a “memory leak”. Valgrind uses this stricter definition of the term “memory leak”. This is the type of leak which can potentially cause significant heap depletion, especially for long lived processes.

The “still reachable” category within Valgrind’s leak report refers to allocations that fit only the first definition of “memory leak”. These blocks were not freed, but they could have been freed (if the programmer had wanted to) because the program still was keeping track of pointers to those memory blocks.

In general, there is no need to worry about “still reachable” blocks. They don’t pose the sort of problem that true memory leaks can cause. For instance, there is normally no potential for heap exhaustion from “still reachable” blocks. This is because these blocks are usually one-time allocations, references to which are kept throughout the duration of the process’s lifetime. While you could go through and ensure that your program frees all allocated memory, there is usually no practical benefit from doing so since the operating system will reclaim all of the process’s memory after the process terminates, anyway. Contrast this with true memory leaks which, if left unfixed, could cause a process to run out of memory if left running long enough, or will simply cause a process to consume far more memory than is necessary.

翻译为：

定义”内存泄漏”的方式不止一种. 特别的, 在程序员间常用的主要有两种”内存泄漏”的定义.

第一种常用的定义是, “内存被分配, 随后没有在程序结束前被释放”. 但是, 很多程序员(正确地)主张说符合这一定义的内存泄漏并不会造成问题, 因此并不被认为是真正的内存泄漏.

“内存泄漏”的一种可能更为严格(也更有用)的定义是, “内存被分配后, 由于程序失去了指向被分配内存块的指针而无法被释放”. 换句话说, 你无法释放没有指针指向的内存. 所以这样的内存属于”内存泄漏”. Valgrind用的是这一更为严格的定义. 这类泄漏可能产生严重的堆损耗, 特别是在长期活动的进程中.

Valgrind的泄漏报告中”still reachable”分类指的是只满足第一类定义的内存分配. 这些内存块没有被释放, 但他们是可以被释放的(只要程序员愿意), 因为程序仍然保有指向这些内存块的指针.

一般而言, 不必担心”still reachable”的内存块. 他们不会带来真正的内存泄漏会导致的问题. 比如说, “still reachable”的内存块通常不会导致堆耗尽. 这是因为这些块都是单次分配, 程序在整个生命周期中都保留对他们的指向. 你当然可以梳理整个程序, 保证这些内存块都被释放, 但这实际并没什么好处, 因为操作系统会在进程结束后回收进程的全部内存. 与之相对, 如果真正的内存泄漏没有被修正, 那么就会导致一个进程在运行足够长时间后耗尽所有内存, 或者说消耗比它所必需的多得多的内存.

看来，still reachable类型的内存泄漏，意思是“本该释放的堆内存，并且一直有指针能够访问这些堆内存，但是到程序结束的时候，都没有释放掉”。

上面这大段的引用（英文原文），其实来在https://stackoverflow.com/questions/3840582/still-reachable-leak-detected-by-valgrind，这个SO的问题回答和评论中，还有人提到still reachable的一个特例：FILE指针。没错，当打开一个文件的时候，用了FILE* fp，无论是读取还是写入，如果程序最终没有关闭这个fp，valgrind会把它算作“still reachable”。。。。其实这个说法也不严禁。经过实验我发现，在缺少fclose(fp)的情况下：

  • 如果是FILE* fp = fopen("in.txt", "r")（读取文件）

    • 文件"in.txt"存在，那么会有still reachable问题
    • 不存在"in.txt"，则没有still reachable问题

  • 如果是FILE* fp=fclose("in.txt", "w")（写入文件），则存在still reachable问题（内存不足的极端情况没有测试，2333）

显然，上述关于文件读写的情况，是因为其内部实现中有使用缓冲区来存储需要读取或写入的内容，这个缓冲区应该是从堆上动态分配的内存空间，可以参考APUE（《unix环境高级编程）上的相关描述，例如这篇博客：fopen的默认缓冲大小和setvbuf 用法。

此外，这个SO回答下，还有人给出了still reachable的更精确定义：

Here is a proper explanation of "still reachable":

"Still reachable" are leaks assigned to global and static-local variables. Because valgrind tracks global and static variables it can exclude memory allocations that are assigned "once-and-forget". A global variable assigned an allocation once and never reassigned that allocation is typically not a "leak" in the sense that it does not grow indefinitely. It is still a leak in the strict sense, but can usually be ignored unless you are pedantic.

Local variables that are assigned allocations and not free'd are almost always leaks.

Here is an example

int foo(void)
{
    static char *working_buf = NULL;
    char *temp_buf;
    if (!working_buf) {
         working_buf = (char *) malloc(16 * 1024);
    }
    temp_buf = (char *) malloc(5 * 1024);

    ....
    ....
    ....

}

Valgrind will report working_buf as "still reachable - 16k" and temp_buf as "definitely lost - 5k".

个人比较认同这个回答中的解释，"Still reachable" are leaks assigned to global and static-local variables（Still reachable对应的内存泄漏是说，全局或者static局部变量的指针，对应的内存泄漏）。

使用OpenCV官方的suppression配置文件来忽略内存泄漏

搞了半天发现自己民科了...opencv的github issue中早有人提出了类似“opencv你怎么在valgrind下有内存泄漏”的问题：OpenCV 3.3.0 memory leak for CLAHE Ubuntu 16.04，官方issue发言人也早有了回答：

alalek commented on 21 Sep 2017

Consider to use valgrind suppression files from here:

https://github.com/opencv/opencv/tree/master/platforms/scripts

果然官方的supp文件好用！粘贴opencv.supp如下：

{
   OpenCV-IPP static init
   Memcheck:Cond
   fun:ippicvGetCpuFeatures
   fun:ippicvStaticInit
}

{
   OpenCV-getInitializationMutex
   Memcheck:Leak
   ...
   fun:_ZN2cv22getInitializationMutexEv
}

{
   OpenCV-SingletonBuffer
   Memcheck:Leak
   ...
   fun:_ZN2cv20allocSingletonBufferEm
}

{
   OpenCV-SingletonNewBuffer
   Memcheck:Leak
   ...
   fun:_ZN2cv23allocSingletonNewBufferEm
}

{
   OpenCV-getStdAllocator
   Memcheck:Leak
   ...
   fun:_ZN2cv3Mat15getStdAllocatorEv
}

{
   OpenCV-getOpenCLAllocator
   Memcheck:Leak
   ...
   fun:_ZN2cv3ocl18getOpenCLAllocatorEv
}

{
   OpenCV-getCoreTlsData
   Memcheck:Leak
   fun:_Znwm
   fun:_ZN2cv14getCoreTlsDataEv
}

{
   OpenCV-TLS-getTlsStorage
   Memcheck:Leak
   ...
   fun:_ZN2cvL13getTlsStorageEv
}

{
   OpenCV-TLS-getData()
   Memcheck:Leak
   ...
   fun:*setData*
   fun:_ZNK2cv16TLSDataContainer7getDataEv
}

{
   OpenCV-parallel_for-reconfigure
   Memcheck:Leak
   ...
   fun:_ZN2cv10ThreadPool12reconfigure_Ej
}

{
   OpenCV-parallel_for-instance
   Memcheck:Leak
   fun:_Znwm
   fun:*instance*
   ...
   fun:_ZN2cv13parallel_for_ERKNS_5RangeERKNS_16ParallelLoopBodyEd
}

{
   OpenCV-parallel_for-setNumThreads()
   Memcheck:Leak
   ...
   fun:_ZN2cv13setNumThreadsEi
}

{
   OpenCV-parallel_for-getNumThreads()
   Memcheck:Leak
   ...
   fun:_ZN2cv13getNumThreadsEv
}

{
   OpenCV-getIPPSingelton
   Memcheck:Leak
   ...
   fun:_ZN2cv3ippL15getIPPSingeltonEv
}

{
   OpenCV-getGlobalMatOpInitializer
   Memcheck:Leak
   fun:_Znwm
   fun:_ZN2cvL25getGlobalMatOpInitializerEv
}

{
   OpenCV-CoreTLSData
   Memcheck:Leak
   ...
   fun:_ZNK2cv7TLSDataINS_11CoreTLSDataEE3getEv
}

{
   OpenCV-getThreadID()
   Memcheck:Leak
   ...
   fun:_ZN2cv5utils11getThreadIDEv
}

{
   OpenCV-ThreadID
   Memcheck:Leak
   fun:_Znwm
   fun:_ZNK2cv7TLSDataINS_12_GLOBAL__N_18ThreadIDEE18createDataInstanceEv
}

{
   OpenCV-ThreadID-TLS
   Memcheck:Leak
   fun:_Znwm
   fun:getThreadIDTLS
}

{
   OpenCV-CoreTLS
   Memcheck:Leak
   fun:_Znwm
   fun:_ZNK2cv7TLSDataINS_11CoreTLSDataEE18createDataInstanceEv
}

{
   OpenCV-UMatDataAutoLockerTLS
   Memcheck:Leak
   ...
   fun:_ZN2cvL21getUMatDataAutoLockerEv
}

{
   OpenCV-haveOpenCL
   Memcheck:Leak
   ...
   fun:_ZN2cv3ocl10haveOpenCLEv
}

{
   OpenCV-DNN-getLayerFactoryMutex
   Memcheck:Leak
   ...
   fun:_ZN2cv3dnn*L20getLayerFactoryMutexEv
}

{
   OpenCV-ocl::Context
   Memcheck:Leak
   ...
   fun:_ZN2cv3ocl7Context10getDefaultEb
}

{
   OpenCV-ocl::Device
   Memcheck:Leak
   ...
   fun:_ZN2cv3ocl6Device10getDefaultEv
}

{
   OpenCV-ocl::Queue
   Memcheck:Leak
   ...
   fun:_ZN2cv3ocl5Queue6createERKNS0_7ContextERKNS0_6DeviceE
}

{
   OpenCV-ocl::Program
   Memcheck:Leak
   ...
   fun:_ZN2cv3ocl6Kernel6createEPKcRKNS0_7ProgramE
}

{
   OpenCV-ocl::ProgramEntry
   Memcheck:Leak
   ...
   fun:_ZNK2cv3ocl8internal12ProgramEntrycvRNS0_13ProgramSourceEEv
}

{
   OpenCV-ocl::Context::getProg
   Memcheck:Leak
   ...
   fun:_ZN2cv3ocl7Context7getProgERKNS0_13ProgramSourceERKNS_6StringERS5_
}

{
   OpenCV-getTraceManager()
   Memcheck:Leak
   ...
   fun:getTraceManagerCallOnce
}

{
   OpenCV-ITT
   Memcheck:Leak
   ...
   fun:__itt_*create*
}

{
   OpenCV-gtk_init
   Memcheck:Leak
   ...
   fun:gtk_init
   fun:cvInitSystem
}

{
   OpenCV-FFmpeg-swsscale
   Memcheck:Addr16
   ...
   fun:sws_scale
   fun:_ZN20CvVideoWriter_FFMPEG10writeFrameEPKhiiiii
   fun:cvWriteFrame_FFMPEG
}

{
   OpenCV-GStreamer-gst_init
   Memcheck:Leak
   ...
   fun:gst_init
}

{
   OpenCV-GStreamer-gst_deinit
   Memcheck:Leak
   ...
   fun:gst_deinit
}

{
   OpenCV-GStreamer-gst_init_check
   Memcheck:Leak
   ...
   fun:gst_init_check
}

{
   OpenCV-GStreamer-gst_parse_launch_full-reachable
   Memcheck:Leak
   match-leak-kinds: reachable
   ...
   fun:gst_parse_launch_full
}

{
   OpenCV-OpenEXR-ThreadPool
   Memcheck:Leak
   fun:_Znwm
   fun:_ZN16IlmThread_opencv10ThreadPoolC1Ej
   fun:_ZN16IlmThread_opencv10ThreadPool16globalThreadPoolEv
}

{
   OpenCV-test-gapi-thread-tls
   Memcheck:Leak
   match-leak-kinds: possible
   fun:calloc
   fun:allocate_dtv
   fun:_dl_allocate_tls
}

试试看？测试代码，仅仅是include了opencv而不做任何事情的：

#include 
#include 

#include 
#include 

int main()
{
    return 0;
}

结果输出：

==8700== LEAK SUMMARY:
==8700== definitely lost: 0 bytes in 0 blocks
==8700== indirectly lost: 0 bytes in 0 blocks
==8700== possibly lost: 1,352 bytes in 18 blocks
==8700== still reachable: 237,120 bytes in 1,204 blocks
==8700== of which reachable via heuristic:
==8700== newarray : 1,536 bytes in 16 blocks
==8700== suppressed: 56 bytes in 2 blocks
==8700== Reachable blocks (those to which a pointer was found) are not shown.
==8700== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==8700==
==8700== For counts of detected and suppressed errors, rerun with: -v
==8700== ERROR SUMMARY: 18 errors from 18 contexts (suppressed: 0 from 0)

仍然看到possibly lost，并不完美。

你可能感兴趣的:(内存泄漏检测工具Valgrind与OpenCV搭配使用)

  • 斤斤计较的婚姻到底有多难？ 白心之岂必有为
    很多人私聊我会问到在哪个人群当中斤斤计较的人最多？我都会回答他，一般婚姻出现问题的斤斤计较的人士会非常多，以我多年经验，在婚姻落的一塌糊涂的人当中，斤斤计较的人数占比在20～30%以上，也就是说10个婚姻出现问题的斤斤计较的人有2-3个有多不减。在婚姻出问题当中，有大量的心理不平衡的、尖酸刻薄的怨妇。在婚姻中仅斤斤计较有两种类型：第一种是物质上的，另一种是精神上的。在物质与精神上抠门已经严重的影响
  • QQ群采集助手，精准引流必备神器 2401_87347160 其他经验分享
    功能概述微信群查找与筛选工具是一款专为微信用户设计的辅助工具，它通过关键词搜索功能，帮助用户快速找到相关的微信群，并提供筛选是否需要验证的群组的功能。主要功能关键词搜索：用户可以输入关键词，工具将自动查找包含该关键词的微信群。筛选功能：工具提供筛选机制，用户可以选择是否只显示需要验证或不需要验证的群组。精准引流：通过上述功能，用户可以更精准地找到目标群组，进行有效的引流操作。3.设备需求该工具可以
  • 机器学习与深度学习间关系与区别 ℒℴѵℯ心·动ꦿ໊ོ꫞ 人工智能学习深度学习python
    一、机器学习概述定义机器学习（MachineLearning,ML）是一种通过数据驱动的方法，利用统计学和计算算法来训练模型，使计算机能够从数据中学习并自动进行预测或决策。机器学习通过分析大量数据样本，识别其中的模式和规律，从而对新的数据进行判断。其核心在于通过训练过程，让模型不断优化和提升其预测准确性。主要类型1.监督学习（SupervisedLearning）监督学习是指在训练数据集中包含输入
  • 随笔 | 仙一般的灵气 海思沧海
    仙岛今天，我看了你全部，似乎已经进入你的世界我不知道，这是否是梦幻，还是你仙一般的灵气吸引了我也许每一个人都要有一份属于自己的追求，这样才能够符合人生的梦想，生活才能够充满着阳光与快乐我不知道，我为什么会这样的感叹，是在感叹自己的人生，还是感叹自己一直没有孜孜不倦的追求只感觉虚度了光阴，每天活在自己的梦中，活在一个不真实的世界是在逃避自己，还是在逃避周围的一切有时候我嘲笑自己，嘲笑自己如此的虚无，
  • 一百九十四章. 自相矛盾 巨木擎天
    唉！就这么一夜，林子感觉就像过了很多天似的，先是回了阳间家里，遇到了那么多不可思议的事情儿。特别是小伙伴们，第二次与自己见面时，僵硬的表情和恐怖的气氛，让自己如坐针毡，打从心眼里难受！还有东子，他现在还好吗？有没有被人欺负？护城河里的小鱼小虾们，还都在吗？水不会真的干枯了吧？那对相亲相爱漂亮的太平鸟儿，还好吧！春天了，到了做窝、下蛋、喂养小鸟宝宝的时候了，希望它们都能够平安啊！虽然没有看见家人，也
  • element实现动态路由+面包屑 软件技术NINI vue案例vue.js前端
    el-breadcrumb是ElementUI组件库中的一个面包屑导航组件，它用于显示当前页面的路径，帮助用户快速理解和导航到应用的各个部分。在Vue.js项目中，如果你已经安装了ElementUI，就可以很方便地使用el-breadcrumb组件。以下是一个基本的使用示例：安装ElementUI（如果你还没有安装的话）:你可以通过npm或yarn来安装ElementUI。bash复制代码npmi
  • C语言宏函数 南林yan C语言c语言
    一、什么是宏函数？通过宏定义的函数是宏函数。如下，编译器在预处理阶段会将Add(x,y)替换为((x)*(y))#defineAdd(x,y)((x)*(y))#defineAdd(x,y)((x)*(y))intmain(){inta=10;intb=20;intd=10;intc=Add(a+d,b)*2;cout<
  • C语言如何定义宏函数？ 小九格物 c语言
    在C语言中，宏函数是通过预处理器定义的，它在编译之前替换代码中的宏调用。宏函数可以模拟函数的行为，但它们不是真正的函数，因为它们在编译时不会进行类型检查，也不会分配存储空间。宏函数的定义通常使用#define指令，后面跟着宏的名称和参数列表，以及宏展开后的代码。宏函数的定义方式：1.基本宏函数：这是最简单的宏函数形式，它直接定义一个表达式。#defineSQUARE(x)((x)*(x))2.带参
  • 微服务下功能权限与数据权限的设计与实现 nbsaas-boot 微服务java架构
    在微服务架构下，系统的功能权限和数据权限控制显得尤为重要。随着系统规模的扩大和微服务数量的增加，如何保证不同用户和服务之间的访问权限准确、细粒度地控制，成为设计安全策略的关键。本文将讨论如何在微服务体系中设计和实现功能权限与数据权限控制。1.功能权限与数据权限的定义功能权限：指用户或系统角色对特定功能的访问权限。通常是某个用户角色能否执行某个操作，比如查看订单、创建订单、修改用户资料等。数据权限：
  • 学点心理知识，呵护孩子健康 静候花开_7090
    昨天听了华中师范大学教育管理学系副教授张玲老师的《哪里才是学生心理健康的最后庇护所，超越教育与技术的思考》的讲座。今天又重新学习了一遍，收获匪浅。张玲博士也注意到了当今社会上的孩子由于心理问题导致的自残、自杀及伤害他人等恶性事件。她向我们普及了一个重要的命题，她说心理健康的一些基本命题，我们与我们通常的一些教育命题是不同的，她还举了几个例子，让我们明白我们原来以为的健康并非心理学上的健康。比如如果
  • c++ 的iostream 和 c++的stdio的区别和联系 黄卷青灯77 c++算法开发语言iostreamstdio
    在C++中，iostream和C语言的stdio.h都是用于处理输入输出的库，但它们在设计、用法和功能上有许多不同。以下是两者的区别和联系：区别1.编程风格iostream（C++风格）：C++标准库中的输入输出流类库，支持面向对象的输入输出操作。典型用法是cin（输入）和cout（输出），使用>操作符来处理数据。更加类型安全，支持用户自定义类型的输入输出。#includeintmain(){in
  • 《投行人生》读书笔记 小蘑菇的树洞
    《投行人生》----作者詹姆斯-A-朗德摩根斯坦利副主席40年的职业洞见-很短小精悍的篇幅，比较适合初入职场的新人。第一部分成功的职业生涯需要规划1.情商归为适应能力分享与协作同理心适应能力，更多的是自我意识，你有能力识别自己的情并分辨这些情绪如何影响你的思想和行为。2.对于初入职场的人的建议，细节，截止日期和数据很重要截止日期，一种有效的方法是请老板为你所有的任务进行优先级排序。和老板喝咖啡的好
  • Long类型前后端数据不一致 igotyback 前端
    响应给前端的数据浏览器控制台中response中看到的Long类型的数据是正常的到前端数据不一致前后端数据类型不匹配是一个常见问题，尤其是当后端使用Java的Long类型（64位）与前端JavaScript的Number类型（最大安全整数为2^53-1，即16位）进行数据交互时，很容易出现精度丢失的问题。这是因为JavaScript中的Number类型无法安全地表示超过16位的整数。为了解决这个问
  • Linux下QT开发的动态库界面弹出操作（SDL2） 13jjyao QT类qt开发语言sdl2linux
    需求：操作系统为linux，开发框架为qt，做成需带界面的qt动态库，调用方为java等非qt程序难点：调用方为java等非qt程序，也就是说调用方肯定不带QApplication::exec()，缺少了这个，QTimer等事件和QT创建的窗口将不能弹出(包括opencv也是不能弹出)；这与qt调用本身qt库是有本质的区别的思路：1.调用方缺QApplication::exec()，那么我们在接口
  • 店群合一模式下的社区团购新发展——结合链动 2+1 模式、AI 智能名片与 S2B2C 商城小程序源码 说私域 人工智能小程序
    摘要：本文探讨了店群合一的社区团购平台在当今商业环境中的重要性和优势。通过分析店群合一模式如何将互联网社群与线下终端紧密结合，阐述了链动2+1模式、AI智能名片和S2B2C商城小程序源码在这一模式中的应用价值。这些创新元素的结合为社区团购带来了新的机遇，提升了用户信任感、拓展了营销渠道，并实现了线上线下的完美融合。一、引言随着互联网技术的不断发展，社区团购作为一种新兴的商业模式，在满足消费者日常需
  • 2021-08-26 影幽
    在生活中，女人与男人的感悟往往有所不同。人生最大的舞台就是生活，大幕随时都可能拉开，关键是你愿不愿意表演都无法躲避。在生活中，遇事不要急躁，不要急于下结论，尤其生气时不要做决断，要学会换位思考，大事化小小事化了，把复杂的事情尽量简单处理，千万不要把简单的事情复杂化。永远不要扭曲，别人善意，无药可救。昨天是张过期的支票，明天是张信用卡，只有今天才是现金，要善加利用！执着的攀登者不必去与别人比较自己的
  • 消息中间件有哪些常见类型 xmh-sxh-1314 java
    消息中间件根据其设计理念和用途，可以大致分为以下几种常见类型：点对点消息队列（Point-to-PointMessagingQueues）：在这种模型中，消息被发送到特定的队列中，消费者从队列中取出并处理消息。队列中的消息只能被一个消费者消费，消费后即被删除。常见的实现包括IBM的MQSeries、RabbitMQ的部分使用场景等。适用于任务分发、负载均衡等场景。发布/订阅消息模型（Pub/Sub
  • html 中如何使用 uniapp 的部分方法 某公司摸鱼前端 htmluni-app前端
    示例代码：Documentconsole.log(window);效果展示：好了，现在就可以uni.使用相关的方法了
  • ArcGIS栅格计算器常见公式（赋值、0和空值的转换、补充栅格空值） 研学随笔 arcgis经验分享
    我们在使用ArcGIS时通常经常用到栅格计算器，今天主要给大家介绍我日常中经常用到的几个公式，供大家参考学习。将特定值（-9999）赋值为0，例如-9999.Con("raster"==-9999,0,"raster")2.给空值赋予特定的值（如0）Con(IsNull("raster"),0,"raster")3.将特定的栅格值(如1)赋值为空值，其他保留原值SetNull("raster"==
  • 高级编程--XML+socket练习题 masa010 java开发语言
    1.北京华北2114.8万人上海华东2,500万人广州华南1292.68万人成都华西1417万人（1）使用dom4j将信息存入xml中（2）读取信息，并打印控制台（3）添加一个city节点与子节点（4）使用socketTCP协议编写服务端与客户端，客户端输入城市ID，服务器响应相应城市信息（5）使用socketTCP协议编写服务端与客户端，客户端要求用户输入city对象，服务端接收并使用dom4j
  • 2018-07-23-催眠日作业-#不一样的31天#-66小鹿 小鹿_33
    预言日：人总是在逃避命运的路上，与之不期而遇。心理学上有个著名的名词，叫做自证预言；经济学上也有一个很著名的定律叫做，墨菲定律；在灵修派上，还有一个很著名的法则，叫做吸引力法则。这3个领域的词，虽然看起来不太一样，但是他们都在告诉人们一个现象：你越担心什么，就越有可能会发生什么。同样的道理，你越想得到什么，就应该要积极地去创造什么。无论是自证预言，墨菲定律还是吸引力法则，对人都有正反2个维度的影响
  • 水平垂直居中的几种方法（总结） LJ小番茄 CSS_玄学语言htmljavascript前端csscss3
    1.使用flexbox的justify-content和align-items.parent{display:flex;justify-content:center;/*水平居中*/align-items:center;/*垂直居中*/height:100vh;/*需要指定高度*/}2.使用grid的place-items:center.parent{display:grid;place-item
  • 【一起学Rust | 设计模式】习惯语法——使用借用类型作为参数、格式化拼接字符串、构造函数 广龙宇 一起学Rust#Rust设计模式rust设计模式开发语言
    提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档文章目录前言一、使用借用类型作为参数二、格式化拼接字符串三、使用构造函数总结前言Rust不是传统的面向对象编程语言，它的所有特性，使其独一无二。因此，学习特定于Rust的设计模式是必要的。本系列文章为作者学习《Rust设计模式》的学习笔记以及自己的见解。因此，本系列文章的结构也与此书的结构相同（后续可能会调成结构），基本上分为三个部分
  • 回溯 Leetcode 332 重新安排行程 mmaerd Leetcode刷题学习记录leetcode算法职场和发展
    重新安排行程Leetcode332学习记录自代码随想录给你一份航线列表tickets，其中tickets[i]=[fromi,toi]表示飞机出发和降落的机场地点。请你对该行程进行重新规划排序。所有这些机票都属于一个从JFK（肯尼迪国际机场）出发的先生，所以该行程必须从JFK开始。如果存在多种有效的行程，请你按字典排序返回最小的行程组合。例如，行程[“JFK”,“LGA”]与[“JFK”,“LGB
  • 每日一题——第九十题 互联网打工人no1 C语言程序设计每日一练c语言
    题目：判断子串是否与主串匹配#include#include#include//////判断子串是否在主串中匹配//////主串///子串///boolisSubstring(constchar*str,constchar*substr){intlenstr=strlen(str);//计算主串的长度intlenSub=strlen(substr);//计算子串的长度//遍历主字符串，对每个可能得
  • Python数据分析与可视化实战指南 William数据分析 pythonpython数据
    在数据驱动的时代，Python因其简洁的语法、强大的库生态系统以及活跃的社区，成为了数据分析与可视化的首选语言。本文将通过一个详细的案例，带领大家学习如何使用Python进行数据分析，并通过可视化来直观呈现分析结果。一、环境准备1.1安装必要库在开始数据分析和可视化之前，我们需要安装一些常用的库。主要包括pandas、numpy、matplotlib和seaborn等。这些库分别用于数据处理、数学
  • C#中使用split分割字符串 互联网打工人no1 c#
    1、用字符串分隔：usingSystem.Text.RegularExpressions;stringstr="aaajsbbbjsccc";string[]sArray=Regex.Split(str,"js",RegexOptions.IgnoreCase);foreach(stringiinsArray)Response.Write(i.ToString()+"");输出结果：aaabbbc
  • 《庄子.达生9》 钱江潮369
    【原文】孔子观于吕梁，县水三十仞，流沫四十里，鼋鼍鱼鳖之所不能游也。见一丈夫游之，以为有苦而欲死也，使弟子并流而拯之。数百步而出，被发行歌而游于塘下。孔子从而问焉，曰：“吾以子为鬼，察子则人也。请问，‘蹈水有道乎’”曰：“亡，吾无道。吾始乎故，长乎性，成乎命。与齐俱入，与汩偕出，从水之道而不为私焉。此吾所以蹈之也。”孔子曰：“何谓始乎故，长乎性，成乎命？”曰：“吾生于陵而安于陵，故也；长于水而安于
  • Python中os.environ基本介绍及使用方法 鹤冲天Pro #Pythonpython服务器开发语言
    文章目录python中os.environos.environ简介os.environ进行环境变量的增删改查python中os.environ的使用详解1.简介2.key字段详解2.1常见key字段3.os.environ.get()用法4.环境变量的增删改查和判断是否存在4.1新增环境变量4.2更新环境变量4.3获取环境变量4.4删除环境变量4.5判断环境变量是否存在python中os.envi
  • 水泥质量纠纷案代理词 徐宝峰律师
    贵州领航建设有限公司诉贵州纳雍隆庆乌江水泥有限公司产品质量纠纷案代理词尊敬的审判长、审判员：贵州千里律师事务所接受被告贵州纳雍隆庆乌江水泥有限公司的委托，指派我担任其诉讼代理人，参加本案的诉讼活动。下面，我结合本案事实和相关法律规定发表如下代理意见，供合议庭评议案件时参考：原告应当举证证明其遭受的损失与被告生产的水泥质量的因果关系。首先水泥是一种粉状水硬性无机胶凝材料。加水搅拌后成浆体，能在空气中
  • 对股票分析时要注意哪些主要因素？ 会飞的奇葩猪 股票 分析 云掌股吧
    　　众所周知，对散户投资者来说，股票技术分析是应战股市的核心武器，想学好股票的技术分析一定要知道哪些是重点学习的，其实非常简单，我们只要记住三个要素：成交量、价格趋势、振荡指标。     一、成交量 　　大盘的成交量状态。成交量大说明市场的获利机会较多，成交量小说明市场的获利机会较少。当沪市的成交量超过150亿时是强市市场状态，运用技术找综合买点较准；
  • 【Scala十八】视图界定与上下文界定 bit1129 scala
    Context Bound，上下文界定，是Scala为隐式参数引入的一种语法糖，使得隐式转换的编码更加简洁。   隐式参数 首先引入一个泛型函数max，用于取a和b的最大值 def max[T](a: T, b: T) = { if (a > b) a else b }  因为T是未知类型，只有运行时才会代入真正的类型，因此调用a >
  • C语言的分支——Object-C程序设计阅读有感 darkblue086 applec框架cocoa
    自从1972年贝尔实验室Dennis Ritchie开发了C语言，C语言已经有了很多版本和实现，从Borland到microsoft还是GNU、Apple都提供了不同时代的多种选择，我们知道C语言是基于Thompson开发的B语言的，Object-C是以SmallTalk-80为基础的。和C++不同的是，Object C并不是C的超集，因为有很多特性与C是不同的。 Object-C程序设计这本书
  • 去除浏览器对表单值的记忆 周凡杨 html记忆autocompleteform浏览
                                       &n
  • java的树形通讯录 g21121 java
    最近用到企业通讯录，虽然以前也开发过，但是用的是jsf，拼成的树形，及其笨重和难维护。后来就想到直接生成json格式字符串，页面上也好展现。 // 首先取出每个部门的联系人 for (int i = 0; i < depList.size(); i++) { List<Contacts> list = getContactList(depList.get(i
  • Nginx安装部署 510888780 nginxlinux
    Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、示例配置文件和低系统资源
  • java servelet异步处理请求 墙头上一根草 ｊａｖａ异步返回ｓｅｒｖｌｅｔ
    servlet3.0以后支持异步处理请求，具体是使用AsyncContext ，包装httpservletRequest以及httpservletResponse具有异步的功能，        final AsyncContext ac = request.startAsync(request, response);   ac.s
  • 我的spring学习笔记8-Spring中Bean的实例化 aijuans Spring 3
    在Spring中要实例化一个Bean有几种方法： 1、最常用的（普通方法） <bean id="myBean" class="www.6e6.org.MyBean" /> 使用这样方法，按Spring就会使用Bean的默认构造方法，也就是把没有参数的构造方法来建立Bean实例。 （有构造方法的下个文细说） 2、还
  • 为Mysql创建最优的索引 annan211 mysql索引
    索引对于良好的性能非常关键，尤其是当数据规模越来越大的时候，索引的对性能的影响越发重要。 索引经常会被误解甚至忽略，而且经常被糟糕的设计。 索引优化应该是对查询性能优化最有效的手段了，索引能够轻易将查询性能提高几个数量级，最优的索引会比 较好的索引性能要好2个数量级。 1 索引的类型 (1) B-Tree 不出意外，这里提到的索引都是指 B-
  • 日期函数 百合不是茶 oraclesql日期函数查询
      ORACLE日期时间函数大全 TO_DATE格式(以时间:2007-11-02 13:45:25为例) Year: yy two digits 两位年 显示值:07 yyy three digits 三位年 显示值:007
  • 线程优先级 bijian1013 javathread多线程java多线程
    多线程运行时需要定义线程运行的先后顺序。 线程优先级是用数字表示，数字越大线程优先级越高，取值在1到10，默认优先级为5。 实例： package com.bijian.study; /** * 因为在代码段当中把线程B的优先级设置高于线程A,所以运行结果先执行线程B的run()方法后再执行线程A的run()方法 * 但在实际中，JAVA的优先级不准，强烈不建议用此方法来控制执
  • 适配器模式和代理模式的区别 bijian1013 java设计模式
    一.简介        适配器模式：适配器模式（英语：adapter pattern）有时候也称包装样式或者包装。将一个类的接口转接成用户所期待的。一个适配使得因接口不兼容而不能在一起工作的类工作在一起，做法是将类别自己的接口包裹在一个已存在的类中。      &nbs
  • 【持久化框架MyBatis3三】MyBatis3 SQL映射配置文件 bit1129 Mybatis3
     SQL映射配置文件一方面类似于Hibernate的映射配置文件，通过定义实体与关系表的列之间的对应关系。另一方面使用<select>,<insert>,<delete>，<update>元素定义增删改查的SQL语句， 这些元素包含三方面内容 1. 要执行的SQL语句 2. SQL语句的入参，比如查询条件 3. SQL语句的返回结果
  • oracle大数据表复制备份个人经验 bitcarter oracle大表备份大表数据复制
    前提：    数据库仓库A（就拿oracle11g为例）中有两个用户user1和user2,现在有user1中有表ldm_table1,且表ldm_table1有数据5千万以上，ldm_table1中的数据是从其他库B（数据源）中抽取过来的，前期业务理解不够或者需求有变，数据有变动需要重新从B中抽取数据到A库表ldm_table1中。    
  • HTTP加速器varnish安装小记 ronin47 http varnish 加速
    上午共享的那个varnish安装手册，个人看了下，有点不知所云，好吧~看来还是先安装玩玩！ 苦逼公司服务器没法连外网，不能用什么wget或yum命令直接下载安装，每每看到别人博客贴出的在线安装代码时，总有一股羡慕嫉妒“恨”冒了出来。。。好吧，既然没法上外网，那只能麻烦点通过下载源码来编译安装了！ Varnish 3.0.4下载地址： http://repo.varnish-cache.org/
  • java-73-输入一个字符串，输出该字符串中对称的子字符串的最大长度 bylijinnan java
    public class LongestSymmtricalLength { /* * Q75题目：输入一个字符串，输出该字符串中对称的子字符串的最大长度。 * 比如输入字符串“google”，由于该字符串里最长的对称子字符串是“goog”，因此输出4。 */ public static void main(String[] args) { Str
  • 学习编程的一点感想 Cb123456 编程感想Gis
           写点感想，总结一些，也顺便激励一些自己.现在就是复习阶段，也做做项目.      本专业是GIS专业，当初觉得本专业太水，靠这个会活不下去的，所以就报了培训班。学习的时候，进入状态很慢，而且当初进去的时候，已经上到Java高级阶段了，所以.....，呵呵，之后有点感觉了，不过，还是不好好写代码，还眼高手低的，有
  • [能源与安全]美国与中国 comsci 能源
         现在有一个局面：地球上的石油只剩下N桶，这些油只够让中国和美国这两个国家中的一个顺利过渡到宇宙时代，但是如果这两个国家为争夺这些石油而发生战争，其结果是两个国家都无法平稳过渡到宇宙时代。。。。而且在战争中，剩下的石油也会被快速消耗在战争中，结果是两败俱伤。。。       在这个大
  • SEMI-JOIN执行计划突然变成HASH JOIN了 的原因分析 cwqcwqmax9 oracle
    甲说： A B两个表总数据量都很大，在百万以上。 idx1  idx2字段表示是索引字段 A B 两表上都有 col1字段表示普通字段 select xxx from A where A.idx1 between mmm and nnn      and exists (select 1 from B where B.idx2 =
  • SpringMVC-ajax返回值乱码解决方案 dashuaifu AjaxspringMVCresponse中文乱码
      SpringMVC-ajax返回值乱码解决方案   一：（自己总结，测试过可行） ajax返回如果含有中文汉字，则使用：（如下例：） @RequestMapping(value="/xxx.do")       public @ResponseBody void getPunishReasonB
  • Linux系统中查看日志的常用命令 dcj3sjt126com OS
    因为在日常的工作中，出问题的时候查看日志是每个管理员的习惯，作为初学者，为了以后的需要，我今天将下面这些查看命令共享给各位 cat tail -f 日 志 文 件 说 明 /var/log/message 系统启动后的信息和错误日志，是Red Hat Linux中最常用的日志之一 /var/log/secure 与安全相关的日志信息 /var/log/maillog 与邮件相关的日志信
  • [应用结构]应用 dcj3sjt126com PHPyii2
    应用主体 应用主体是管理 Yii 应用系统整体结构和生命周期的对象。 每个Yii应用系统只能包含一个应用主体，应用主体在 入口脚本中创建并能通过表达式 \Yii::$app 全局范围内访问。 补充: 当我们说"一个应用"，它可能是一个应用主体对象，也可能是一个应用系统，是根据上下文来决定[译：中文为避免歧义，Application翻译为应
  • assertThat用法 eksliang JUnitassertThat
    junit4.0  assertThat用法 一般匹配符1、assertThat( testedNumber, allOf( greaterThan(8), lessThan(16) ) ); 注释： allOf匹配符表明如果接下来的所有条件必须都成立测试才通过，相当于“与”（&&） 2、assertThat( testedNumber, anyOf( g
  • android点滴2 gundumw100 应用服务器android网络应用OSHTC
    如何让Drawable绕着中心旋转？ Animation a = new RotateAnimation(0.0f, 360.0f, Animation.RELATIVE_TO_SELF, 0.5f, Animation.RELATIVE_TO_SELF,0.5f); a.setRepeatCount(-1); a.setDuration(1000); 如何控制Andro
  • 超简洁的CSS下拉菜单 ini htmlWeb工作html5css
    效果体验：http://hovertree.com/texiao/css/3.htmHTML文件： <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>简洁的HTML+CSS下拉菜单-HoverTree</title>
  • kafka consumer防止数据丢失 kane_xie kafkaoffset commit
    kafka最初是被LinkedIn设计用来处理log的分布式消息系统，因此它的着眼点不在数据的安全性（log偶尔丢几条无所谓），换句话说kafka并不能完全保证数据不丢失。   尽管kafka官网声称能够保证at-least-once，但如果consumer进程数小于partition_num，这个结论不一定成立。   考虑这样一个case，partiton_num=2
  • @Repository、@Service、@Controller 和 @Component mhtbbx DAOspringbeanprototype
    @Repository、@Service、@Controller 和 @Component 将类标识为Bean Spring 自 2.0 版本开始，陆续引入了一些注解用于简化 Spring 的开发。@Repository注解便属于最先引入的一批，它用于将数据访问层 (DAO 层 ) 的类标识为 Spring Bean。具体只需将该注解标注在 DAO类上即可。同时，为了让 Spring 能够扫描类
  • java 多线程高并发读写控制 误区 qifeifei java thread
    先看一下下面的错误代码，对写加了synchronized控制，保证了写的安全，但是问题在哪里呢？ public class testTh7 { private String data; public String read(){ System.out.println(Thread.currentThread().getName() + "read data "
  • mongodb replica set(副本集)设置步骤 tcrct javamongodb
    网上已经有一大堆的设置步骤的了，根据我遇到的问题，整理一下，如下： 首先先去下载一个mongodb最新版，目前最新版应该是2.6 cd /usr/local/bin wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.6.0.tgz tar -zxvf mongodb-linux-x86_64-2.6.0.t
  • rust学习笔记 wudixiaotie 学习笔记
    1.rust里绑定变量是let，默认绑定了的变量是不可更改的，所以如果想让变量可变就要加上mut。 let x = 1; let mut y = 2; 2.match 相当于erlang中的case，但是case的每一项后都是分号，但是rust的match却是逗号。 3.match 的每一项最后都要加逗号，但是最后一项不加也不会报错，所有结尾加逗号的用法都是类似。 4.每个语句结尾都要加分
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他