valgrind

4.1 C内存管理： C标准内存管理函数： (1).malloc(size_t size)：分配size个字节，并返回一个指向分配的内存的指针。分配的内存未被初始化为一个已知值。 (2).aligned_alloc(size_t alignment, size_t size)：为一个对象分配size个字节的空间，此对象的对齐方式是alignment指定的。alignment的值必须是实现支持的一种有效的对齐方式，size的值必须是alignment的整数倍，否则行为就是未定义的。此函数返回一个指向分配的空间的指针，如果分配失败，则返回一个空指针。 (3).realloc(void* p, size_t size)：将p所指向的内存块的大小改为size个字节。新大小和旧大小中较小的值那部分内存所包含的内容不变，新分配的内存未作初始化，因此将有不确定的值。如果内存请求不能被成功分配，那么旧的对象保持不变，而且没有值被改变。如果p是一个空指针，则该调用等价于malloc(size)；如果size等于0，则该调用等价于free(p)，但这种释放内存的用法应该避免。 (4).calloc(size_t nmemb, size_t size)：为数组分配内存，(该数组共有nmemb个元素，每个元素的大小为size个字节)并返回一个指向所分配的内存的指针。所分配的内存的内容全部被设置为0。

$ sudo apt-get install -y valgrind 来源： oschina 链接： https://my.oschina.net/u/4333262/blog/4266933

导读 排除故障指南：MySQL运行内存不足时应采取的措施？ 原文出处 ：《What To Do When MySQL Runs Out of Memory: Troubleshooting Guide》 https://www.percona.com/blog/2018/06/28/what-to-do-when-mysql-runs-out-of-memory-troubleshooting-guide/ 原文作者： Alexander Rubin 关键词： memory、memory leaks、Memory Usage、MySQL server memory usage、MySQL Troubleshooting、Troubleshooting MySQL、troubleshooting tips Troubleshooting crashes is never a fun task, especially if MySQL does not report the cause of the crash. For example, when MySQL runs out of memory. Peter Zaitsev wrote a blog post in 2012: Troubleshooting MySQL Memory Usage with a lots of

作者：孙祚龙 爱可生南区分公司交付服务部成员，实习工程师。负责公司产品问题排查及日常运维工作。 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 引言 前阵子处理这样一个案例，某客户的实例 mysqld 进程内存经常持续增加导致最终被 OOM killer。作为 DBA 肯定想知道有哪些原因可能会导致 OOM（内存溢出）。 此篇文章叙述个人的一些拙见~ 先介绍下这位朋友：OOM-killer OOM Killer(Out of Memory Killer) 是当系统内存严重不足时 linux 内核采用的杀掉进程，释放内存的机制。 OOM Killer 通过检查所有正在运行的进程，然后根据自己的算法给每个进程一个 badness 分数，拥有最高 badness 分数的进程将会在内存不足时被杀掉。 它打分的算法如下: 某一个进程和它所有的子进程都占用了很多内存的将会打一个高分。 为了释放足够的内存来解决这种情况，将杀死最少数量的进程（最好是一个进程）。 内核进程和其他较重要的进程会被打成相对较低的分。 上面打分的标准意味着，当 OOM killer 选择杀死的进程时，将选择一个使用大量内存，有很多子进程且不是系统进程的进程。 简单来讲，oom-killer 的原则就是损失最小、收益最大，因此它会让杀死的进程数尽可能小、释放的内存尽可能大

转自：https://blog.csdn.net/z2066411585/article/details/81239446 用法：配置[选项] 选项：[描述后括号中的默认值] 帮助选项： --help 打印此消息 --quiet 抑制显示信息输出 --list-decoders 显示所有可用的解码器 --list-encoders 显示所有可用的编码器 --list-hwaccels 显示所有可用的硬件加速器 --list-demuxers 显示所有可用的解复用器 --list-muxers 显示所有可用的复用器 --list-parsers 显示所有可用的解析器 --list-protocols 显示所有可用的协议 --list-bsfs 显示所有可用的比特流过滤器 --list-indevs 显示所有可用的输入设备 --list-outdevs 显示所有可用的输出设备 --list-filters 显示所有可用的过滤器 标准选项： --logfile = FILE日志测试并输出到FILE [ffbuild / config.log] --disable-logging不记录配置调试信息 - 如果生成任何配置警告，则-fatal-warnings将失败 --prefix = PREFIX安装在PREFIX [/ usr / local] -bindir = DIR在DIR

Valgrind TOC Valgrind Valgrind包括如下一些工具： 用法： 编译最好带上-g -O0，用于生成debug版本和取消编译优化。 valgrind --tool=memcheck --leak-check=full ./test Memcheck。这是valgrind应用最广泛的工具，一个重量级的内存检查器，能够发现开发中绝大多数内存错误使用情况，比如：使用未初始化的内存，使用已经释放了的内存，内存访问越界等。这也是本文将重点介绍的部分。 Callgrind。它主要用来检查程序中函数调用过程中出现的问题。 Cachegrind。它主要用来检查程序中缓存使用出现的问题。 Helgrind。它主要用来检查多线程程序中出现的竞争问题。 Massif。它主要用来检查程序中堆栈使用中出现的问题。 Extension。可以利用core提供的功能，自己编写特定的内存调试工具。 来自为知笔记(Wiz) 来源： oschina 链接： https://my.oschina.net/u/4353890/blog/3274764

【推荐阅读】微服务还能火多久？>>> ys@ysm:tests$ valgrind --tool=memcheck --leak-check=full ./a.out ==7503== Memcheck, a memory error detector ==7503== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==7503== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==7503== Command: ./a.out ==7503== tid=7503, constructing 0x5c3e0b0 tid=7510, 0x5c3e0b0 name=only one tid=7503, 0x5c3e0b0 name=only one, changed tid=7503, constructing TestNoDestroy 0x5c3e3c0 with valgrind, you should see 1-byte memory leak. tid=7503, destructing 0x5c3e0b0 only one, changed ==7503== ==7503== HEAP SUMMARY: