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搭配使用)

  • 京东优惠券是真的吗?店铺优惠券如何设置?- 氧惠_飞智666999
    京东优惠券，是真金白银的实惠，还是空洞的虚假宣传？接下来，让我们一起探寻这个问题的答案。氧惠APP（带货领导者）——是与以往完全不同的抖客+淘客app！2024全新模式，我的直推也会放到你下面。主打：带货高补贴，深受各位带货团队长喜爱（每天出单带货几十万单）。注册即可享受高补贴+0撸+捡漏等带货新体验。送万元推广大礼包，教你如何1年做到百万团队。首先，我们要明确一点，京东作为一家知名的电商平台，有
  • 爱孩子是父母的天性，有意识地爱孩子是培养孩子安全感和勇气的最重要的方法。 纯洁的无瑕疵
    爱孩子是父母的天性，有意识地爱孩子是培养孩子安全感和勇气的最重要的方法。当孩子被无条件地爱着的时候，他的自信心会大增，在他的心灵中会感受到自我价值的产生。很多家长对孩子的爱是有条件的，要求孩子做出相应的行为或取得相应的成绩，然后再给予孩子与之相适应的爱，家长与孩子的关系成了“生意”关系。这种有条件的爱，极大地扼杀了孩子的自尊心。孩子会觉得自己不够好，自己还需要做出相应的动作，父母才能爱自己。孩子在
  • linux-L3-linux 复制文件 robot_大菜鸟 linux_dotilinux
    linux中要将文件file1.txt复制到目录dir中，可以使用以下命令cpfile1.txtdir/复制文件cp/path/to/source/file/path/to/destination移动mv/path/to/source/file/path/to/destination复制文件夹内的文件cp-a/path/to/source/file/path/to/destination将文件夹内
  • K8S - Emptydir - 取代ELK 使用fluentd 构建logging saidcar nvd11 K8Skubernetes
    由于k8s的无状态service通常部署在多个POD中，实现多实例面向高并发。但是k8s本身并没有提供集中查询多个pod的日志的功能其中1个常见方案就是ELK.本文的方案是利用fluentdsidecar和emptydir把多个pod的日志导向到bigquery的table中。Emptydir的简介Kubernetes中的EmptyDir是一种用于容器之间共享临时存储的空目录卷类型。EmptyDi
  • Linux下载压缩包：tar.gz、zip、tar.bz2格式全攻略 promise524 Linuxlinux运维服务器后端bashshell
    在Linux中，下载各种格式的压缩包（如.tar.gz、.zip、.tar.bz2等）通常使用命令行工具如wget和curl。1.使用wget下载压缩包wget是Linux中最常用的文件下载工具，支持HTTP、HTTPS、FTP等协议，可以直接从命令行下载文件。基本命令：wget[URL]下载.tar.gz文件wgethttps://test.com/archive.tar.gz此命令将从指定的U
  • 剧本杀一出好戏凶手剧透真相答案解析复盘结局攻略 VX搜_奶茶剧本杀
    完整真相解析胃搜奶茶剧本杀。故事的核心事件是关于“绝代双跤”的先后两个女一号发生意外。第一次，女一号李清灵出了交通事故，被撞伤入院。为此暂时退出演艺圈。李清灵极度虚荣。同时与数名富豪交往。利用美色赚取钱财，这些都被黄于鹤知晓。但孔良辰没想到，女一号住院后。王成仁竟通过各种手段使刚刚出道的韩朵朵担任了女一号。第二次，由韩朵朵担任女一号。孔良辰自然对这个结果不满意，但是她深知黄于鹤是个危险人物，不会留
  • 由于直接在回答中完整展示一个复杂如游戏商城的代码系统并不现实（会超出限制且难以维护），我将为你概述一个简化的游戏商城系统的架构，并提供关键部分的示例代码，这些代码将涵盖几种不同的编程语言。 NewmanEdwarda2 游戏架构
    架构概述pzswcc.cn前端：用于展示商品、处理用户交互（如查看商品详情、添加到购物车、结账等）。后端：处理业务逻辑（如商品库存管理、订单处理、用户认证等），与数据库交互。数据库：存储商品信息、用户信息、订单信息等。示例代码前端（HTML+JavaScript）HTML（简单页面布局）html游戏商城游戏商城JavaScript(使用FetchAPI调用后端API)javascript//假设后
  • 刘航瑞的小生活 吴霞1988
    刘航瑞是个性格超级外向的孩子，善于与人相处，进入任何环境中他都可以不胆怯从容面对，记得刘航瑞出生时，他是个很安静的孩子，由于他的爸爸非常爱他(其实每个父母都是很爱孩子的)从刘航瑞1岁后他爸爸每次出差或者学习什么的都尽可能带上他，尽可能去陪伴他，看多了听多了懂的自然也多了，古人云：读万卷书去不如行万里路。他从小到现在都属于那种喜欢舞台的孩子，其实对于这块他的成长我和他爸爸的心德就是鼓励他与激励他，每
  • 京东购物返现金是真的吗?京东有什么其他优惠? 氧惠帮朋友一起省
    哎呀，亲爱的小仙女们、小帅哥们，你们是不是经常在京东上买东西呀？告诉你们一个超级大秘密，京东购物返现金是真的哦！这不是骗人的，是真的可以拿到现金回馈呢！氧惠APP（带货领导者）——是与以往完全不同的抖客+淘客app！2024全新模式，我的直推也会放到你下面。主打：带货高补贴，深受各位带货团队长喜爱（每天出单带货几十万单）。注册即可享受高补贴+0撸+捡漏等带货新体验。送万元推广大礼包，教你如何1年做
  • 《爱心与教育》金句摘抄（一） 教育行走林
    最近在看李镇西老师的《爱心与教育》，感觉有很多需要摘抄的经典教育“金句”，今天和大家分享几句：1缺乏爱的教育，是伪教育，它用爱取代一切，也不可能有真正的教育。教师还要有职业精神，要有民主与平等的现代意识，要有渊博的学科素养和厚重的文化底蕴，一句话，要有不可替代的专业能力。2教育之爱应该是充满民主精神的爱，民主的核心是对人的尊重。因此，充满民主的爱同样意味着尊重。尊重学生的人，尊重学生的情感，尊重学
  • 学习中华传统文化与身心健康讲座第八集感悟 8feeff7bc6bc
    孝敬父母，天经地义，百善孝为先，一个孝字全家安从小就听老人讲过！自认为对待父母长辈还算孝敬！尽量让老人晚年幸福，尽量完成老人心愿，老人的牵挂我都一一解决，让老人高兴经常夸奖，可是听完老师讲课我还远远不够啊！母亲十月怀胎，忍受痛苦把我生下来，那个年代吃不饱饭！我们还要吃她的奶水！吃那么多1400多斤！母亲是用爱把我抚养长大！我做这么点事简直就是九牛一毛！有时还跟她大吼大叫！哥兄弟吵架让她老人家心多难
  • 我是谁，是一个非常重要的问题 丁金波波种快乐
    一外卖小哥稳稳地把车停到了门卫大爷脚边。"你是谁？""送外卖的。""你从哪来？""...""你要到哪去？""大爷，这您的，再等一会儿就凉了"……我是谁？我从哪来？我要到哪去？这是哲学三问，现在被调侃为“保安三问”。前两天，我也与一位门卫保安发生了交集。周末，开车去讲课。教室在一个封闭的小区里，去之前，主办方告诉我说，车子是可以直接开进去。当我到达小区门口的时候，被门卫的大爷拦住了。他说：“非本小区
  • 思念成疾 药石无医 知行合一21
    症状反复，回到一年前……不刻意的控制自己，会让自己情绪蔓延-……再蔓延……喜悦感……愉悦感……无法自拔的沉溺……去运动，平板撑，奔跑吧！释放自己的热情，洋溢着小傻瓜的汗水与炙热……专注就是将一件事情做到极致……
  • 网络学习-eNSP配置VRRP 丢爸 网络Linux网络学习
    虚拟路由冗余协议(VirtualRouterRedundancyProtocol，简称VRRP)VRRP广泛应用在边缘网络中，是一种路由冗余协议，它的设计目标是支持特定情况下IP数据流量失败转移不会引起混乱，允许主机使用单路由器，以及即使在实际第一跳路由器使用失败的情形下仍能够维护路由器间的连通性。#配置三层交换机和路由器IP，实现PC1与PC2的通信#---------------------1
  • 一只蓝色球鞋的畅想之旅，想揭开答案请带上你的好奇心 悠爱阅读
    若是你在路边看到一只蓝色球鞋，你会想到什么呢？会是直接路过，还是毫无感触？有这样一群小朋友，用他们的超级可爱神奇的想象力，给我们带来一幕幕一只蓝色球鞋的畅想之旅，它就是[法]安德烈·布沙尔所写的《蓝色球鞋之谜》，跟随孩子们的想象，领悟一种极为奇妙的思绪延展的好奇之旅。在这其中我们可以看见什么呢？一、独特的绘本技巧和出色的画面融合感这本蓝色球鞋之谜依旧延续了作者的创作风格，将现实和虚构、奇幻与熟悉的
  • 【Python技术学习】- 如何搭建一个爬虫代理服务？ xiaoli8748_软件开发 python技术学习python学习爬虫
    由于之前一直在做爬虫采集相关的开发，这个过程那肯定少不了跟「代理IP」打交道，这篇文章就来记录一下，如何实现一个爬虫代理服务，本篇文章主要以讲解思路为主。起因做过爬虫的人应该都知道，抓的网站和数据多了，如果爬虫抓取速度过快，免不了触发网站的防爬机制。而这些网站应对爬虫的办法，几乎用的同一招就是封IP。那么我们还想稳定、持续地抓取这些网站的数据，如何解决呢？一般解决方案有2个：使用同一个服务器IP抓
  • #育人宝贝教师百日行动派#day26 Allian_8e9b
    每日5000步√今日所读《3-6岁儿童学习与发展指南》4-5岁幼儿的发展指标1.能自己穿脱衣服、鞋袜、扣纽扣4-5岁的幼儿生活自理能力逐步提高，注意力集中了，集中精力从事某些活动的时间比以前延长了。2.能整理自己的物品4-5岁幼儿已经能够将脱下来的衣服叠放整齐。图片发自App图片发自App图片发自App图片发自App
  • 直返app安全吗?直返app靠谱吗?直返APP背景揭秘 氧惠好项目
    亲爱的朋友们，你们是不是经常在网上寻找哪里可以下载直返APP？或者对于直返APP的可靠性感到疑虑？让我来给你们揭开这个谜团！氧惠APP（带货领导者）——是与以往完全不同的抖客+淘客app！2023全新模式，我的直推也会放到你下面。主打：带货高补贴，深受各位带货团队长喜爱（每天出单带货几十万单）。注册即可享受高补贴+0撸+捡漏等带货新体验。送万元推广大礼包，教你如何1年做到百万团队。首先，关于直返A
  • 软件测试笔记｜web自动化测试｜Web 自动化测试中，有没有修改过页面元素的属性？如何修改？ 阳哥整理软件测试笔记 web自动化测试自动化
    在Web自动化测试中，可以修改页面元素的属性。通常可以使用JavaScript来实现修改元素属性。以下是使用Selenium结合JavaScript修改页面元素属性的方法：fromseleniumimportwebdriverdriver=webdriver.Chrome()#打开网页driver.get("your_url_here")#找到要修改属性的元素element=driver.find
  • 日记99||开学了 孩子头头儿
    今天，终于开学了！接到复学的通知时，已经是昨天晚上十点多了，我就赶紧转发通知到家长群里，并告知大家需要准备的相关资料，因为疫情，健康码，行程码，核酸检测结果，这些都是必须提前在手机中截图发给我的，并且要逐一审核，最后上交学校！家长们的速度很快，也都非常配合，毕竟每个人都希望疫情快点结束，让每个孩子都能恢复正常的学习生活，再怎么说，孩子在家上课，也真的不是那么一回事儿！在学校上课，有老师的适当督促与
  • 返利APP排行榜的实时更新与维护策略 weixin_836869520 springboot微服务java
    返利APP排行榜的实时更新与维护策略大家好，我是微赚淘客返利系统3.0的小编，是个冬天不穿秋裤，天冷也要风度的程序猿！今天我们来探讨如何实现返利APP排行榜的实时更新与维护策略。排行榜的数据更新是提升用户体验、保持应用竞争力的关键部分。接下来，我将介绍如何通过设计有效的数据更新机制和使用合适的技术栈来实现这一目标。1.数据源的选择与整合排行榜的核心在于数据源。我们需要选择合适的第三方API或内部数
  • linux网关端口映射,如何通过具有Iptables的Linux网关转发端口映射？ 想写小说的轻骑兵 linux网关端口映射
    NAT或网络地址转换是用于处理数据包以便将其重定向到备用地址的通用术语。通常，这用于允许流量超越网络边界。实现NAT的主机通常可以访问两个或多个网络，并配置为在它们之间路由流量。端口转发是将对特定端口的请求转发到另一个主机，网络或端口的过程。由于此过程在运行中修改了数据包的目的地，因此被认为是NAT操作的一种。在本指南中，我们将演示如何iptables使用NAT技术将端口转发到防火墙后面的主机。如
  • idea 启动tomcat 工程_使用IDEA创建JavaWeb项目 部署本地tomcat并运行 心在天上脚在地上 idea启动tomcat工程
    一、下载商业版IDEA二、新建JavaWeb项目1、在菜单栏找到File>>New>>Project2、在弹出的窗口中找到JavaEnterPrise>>WebApplication，点击Next3、填写项目名称，选择项目位置，然后Finish4、在左侧窗口可以看到IDEA创建JavaWeb工程的目录结构，在src中写java代码，在web目录下放jsp页面。三、下载tomacat下载完成后，解压
  • 微信小程序仿微信聊天界面 微特尔普拉斯 微信小程序微信notepad++
    界面结构:消息列表:使用scroll-view实现滚动，每条消息使用view组件包裹，根据消息类型(文本、图片、文件)显示不同内容。输入框区域:包含输入框(textarea)、发送按钮(button)和上传文件按钮(view组件模拟)。头像:使用image组件展示。功能实现:多行输入框高度自适应:使用textarea组件的auto-height属性，并监听linechange事件动态调整高度。消息
  • 把html字符串转为可以被js操作的dom 微特尔普拉斯 javascriptwebnodejavascripthtml前端
    在JavaScript中，您可以使用DOMParserAPI将HTML字符串转换为可操作的DOM节点。以下是具体步骤：1.创建DOMParser实例：constparser=newDOMParser();2.使用parseFromString()方法解析HTML字符串：consthtmlString='Hello,world!';constdoc=parser.parseFromString(ht
  • 解锁网页交互利器：深入浅出 AJAX，用 JavaScript 与后端服务器对话，局部请求刷新数据 微特尔普拉斯 ajaxjavascriptajax前端javascript
    在当今互联网时代，网页早已不再是静态的信息展示平台，而是充满动态交互的应用体验场。而实现这种流畅交互体验的关键技术之一，便是AJAX（AsynchronousJavaScriptandXML）。它允许网页在后台悄无声息地与服务器交换数据，无需刷新整个页面，便可实现内容的动态更新，为用户带来行云流水般的操作体验。在AJAX出现之前，网页开发采用的是前后端不分离的模式。前端开发者编写好HTML和CSS
  • 写一个图片裁剪的js，JavaScript图片裁剪插件PlusCropper 微特尔普拉斯 javascriptnodevuejavascript开发语言ecmascript
    在前端开发中，图片裁剪是一个常见的需求。本文将深入解析一个功能完善的JavaScript图片裁剪插件——PlusCropper，带你一步步了解其实现原理和使用方法。一、插件概述PlusCropper是一个轻量级的JavaScript插件，它允许用户在网页上交互式地裁剪图片。它提供了以下功能：可拖拽和缩放的裁剪框:用户可以通过鼠标或触摸操作来调整裁剪区域的大小和位置。图片旋转:支持图片的顺时针和逆时
  • 看板（Kanban）与Scrum区别 智慧浩海 JIRA教程scrum
    看板和Scrum之间有很多不同之处。下面列出了看板和Scrum之间的区别：对比项Scrum看板计划它有固定的计划，它专注于规划。它从sprint计划开始，以sprint审查结束，回顾性。举行日常会议，以便团队了解后续步骤，优先事项以及之前步骤的经验。它没有固定的计划，也没有每日会议。在看板中，可以随时发生变化，即频繁发生变化。时间线在scrum中，处理具有固定时间持续时间的sprint意味着在一段
  • 淘宝返利微信机器人的消息处理与推送技术 微赚淘客系统开发者 微信机器人
    淘宝返利微信机器人的消息处理与推送技术大家好，我是微赚淘客返利系统3.0的小编，是个冬天不穿秋裤，天冷也要风度的程序猿！今天我们来讨论如何实现淘宝返利微信机器人的消息处理与推送技术。微信机器人可以有效地提升用户体验，通过自动化的消息处理和推送，帮助用户获取最新的返利信息。接下来，我们将详细介绍如何实现这一功能。1.微信机器人的基础架构实现一个淘宝返利微信机器人，我们首先需要了解微信机器人的基础架构
  • 绿色智慧档案馆构想之智慧档案馆环境综合管控一体化平台 盛世宏博智慧档案 智慧档案馆智慧档案馆
    【智慧档案馆整体效果图】智慧档案库房一体化平台通过智慧档案管理，实现智慧档案感知协同处置功能；实现对档案实体的智能化识别、定位、跟踪监控；实现对档案至智能密集架、空气恒湿净化一体设备、安防设备，门禁设备等智能化巡检与即时处理。智慧档案平台基于物联网、云计算、大数据、档案人健康防护、档案安全防护等新技术，实现了对档案的收、管、存、用全业务流程管理；实现了对档案实体资源与数字资源的集中建设与管理；实现
  • 对股票分析时要注意哪些主要因素？ 会飞的奇葩猪 股票 分析 云掌股吧
    　　众所周知，对散户投资者来说，股票技术分析是应战股市的核心武器，想学好股票的技术分析一定要知道哪些是重点学习的，其实非常简单，我们只要记住三个要素：成交量、价格趋势、振荡指标。     一、成交量 　　大盘的成交量状态。成交量大说明市场的获利机会较多，成交量小说明市场的获利机会较少。当沪市的成交量超过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其他