kernel内存泄漏检测工具之slub debug linux (kernel_data_inpage_error 蓝屏错误)

本文目录导航：

• linux kernel内存泄漏检测工具之slub debug
• SLUB_DEBUG配置与调试工具
• SLUBDEBUG原理
• 测试验证与定位泄漏
• 小结与优化
• 深入理解内存泄漏——检查kmemleak
• 内存泄漏检测组件的分析与实现（linux c）-mtrace工具使用

linux kernel内存泄漏检测工具之slub debug

本文聚焦于Linux内核中slub debug工具的内存泄漏检测方法。

slub debug是专门用于跟踪slub内存分配（如kmalloc）的调试工具，这部分内存使用频繁，包含内存踩踏和use after free等异常处理。

由于slub debug的检测效果不及kas（在分配和释放时检查不同标记的内存，存在不及时发现问题的局限），本文主要关注其内存泄漏定位策略。

请注意，尽管文中slub和slab名称有所混用，实际Linux版本中默认使用slub。

slab命名与slub或slab的区别取决于内核配置，即是否启用CONFIG_SLUB。

实验和分析基于CONFIG_SLUB=y。

SLUB_DEBUG配置与调试工具

为了定位内存泄漏，可以使用内核自带的slabinfo小工具。

该工具能快速识别泄漏类型。

调试节点的设置允许对特定类型的slub内存泄漏进行监控。

SLUBDEBUG原理

SLUB_DEBUG原理涉及slub内存分配的基本流程，包括内存的分配、使用和释放。

检测内存泄漏的方法则是通过监控SUnreclaim size的变化。

如果在一段时间内SUnreclaim size增量超过预设阈值（如600M），则表明存在内存泄漏。

测试验证与定位泄漏

测试时，可以通过记录启动时的SUnreclaim size并每隔一段时间重新测量，以检测内存泄漏。

通过slabinfo或使用slabinfo工具分析泄漏的slub类型。

然后，开启指定类型的slub内存泄漏调试，并通过分析alloc_traces文件定位泄漏调用栈及次数。

小结与优化

开启SLUB_DEBUG配置（默认打开CONFIG_SLUB_DEBUG）对性能无显著影响，但无法在出现问题后动态开启。

对于问题复现概率低的情况，商用版本应谨慎开启slub泄漏检测，避免对用户内存造成过大影响。

优化方案包括利用vendor hook机制动态修改kmalloc_caches，实现针对kmalloc的动态调试。

参考资源包括极致Linux内核、SLUB DEBUG原理、等，提供了关于Linux内存管理的深入分析，帮助理解内存泄漏检测工具与策略。

深入理解内存泄漏——检查kmemleak

深入理解内存泄漏——检查kmemleak内存泄漏是我们工作中常遇到的问题，严重影响系统性能。

本文主要探讨内核态内存泄漏的特征与解决方法，以及介绍kmemleak工具的原理与使用。

内存泄漏主要分为用户态与内核态两种，我们本文将重点分析内核态内存泄漏。

内核态内存泄漏的常见类型包括频发性与一次性/偶发性。

频发性内存泄漏可通过/proc/meminfo等信息定位；而一次性/偶发性内存泄漏较难定位，导致系统压力增大。

kmemleak工具能检测各种类型的内存泄漏，提供解决路径。

kmemleak是内核空间内存泄漏检测工具，通过暴力扫描内存块，若找不到指向内存块的指针，则视为内存泄漏。

内存块对象有黑色、白色、灰色三种状态，通过count与min_count判断内存泄漏风险。

kmemleak_object结构描述内存块，包含状态标志位、使用计数、起始地址、大小等。

扫描步骤包括初始化、创建、删除对象，以及全局变量管理。

kmemleak_init配置了初始化参数。

create_object创建对象并初始化，加入树与链表管理。

delete_object_full与delete_object_part分别删除对象与切割对象。

create_object接口解释了vmalloc内存块处理逻辑。

kmemleak_scan_thread实现内存泄漏扫描流程。

scan_gray_list扫描灰色链表，scan_object扫描对象内容，scan_block扫描指定内存地址范围。

误报与漏报问题通过配置函数解决。

kmemleak工具提供简便的使用方法，执行`mount -t debugfs nodev /sys/kernel/debug/`并进行`echo scan > /sys/kernel/debug/kmemleak`操作。

通过`cat /sys/kernel/debug/kmemleak`命令获取检测结果。

为了更深入了解内存泄漏检测，可以参考内核文档Documentation/dev-tools/，获取详细使用说明与案例分析。

内存泄漏检测组件的分析与实现（linux c）-mtrace工具使用

内存泄漏的产生原因主要在于在堆上使用了malloc、realloc、calloc等函数分配了内存空间，但未使用free函数释放对应的空间。

这样会导致一段时间后，由于只存在内存分配操作而未释放操作，堆内存资源消耗过度，无法再分配合适的内存，最终可能导致程序崩溃。

预防内存泄漏的最佳策略是通过实现内存泄漏检测组件。

该组件主要分为两个部分：一是知道内存是否发生泄漏，二是定位引起内存泄漏的代码行。

关于如何判断内存是否泄漏，可以使用链表或文件系统记录内存分配与释放情况。

将每次分配内存的操作信息（如地址和大小）记录在链表或文件中，释放内存时同步释放相应记录。

检查记录数据是否为空可判断是否存在内存泄漏。

若使用文件记录，运行前清空文件夹，每次malloc生成对应文件，free后删除文件，最后若文件夹仍有文件，说明存在内存泄漏。

定位内存泄漏的具体代码行可以通过使用宏定义、__FILE__、FUNCTION、__LINE__等C语言特性或使用builtin_return_address() API来实现。

宏定义方法可以避免递归调用问题，更易于追踪内存泄漏发生的具体代码位置。

常用的内存泄漏检测工具包括valgrind、mtrace等。

使用这些工具可以帮助开发者更加直观地检测内存泄漏问题。

在代码运行环境中，重要的是确保编译环境支持所需的功能。

例如，Ubuntu16.04和gcc 5.4编译环境是一个合适的例子，但需要注意代码在不同编译器或环境下的兼容性问题。

实现内存泄漏检测组件的三种常见方式包括重写malloc/free函数、使用宏定义以及mtrace工具的实现。

其中，重写malloc/free函数的方法虽然直观，但存在线程安全问题，可能引发递归调用。

宏定义方式可以有效避免此类问题，实现更为简单。

mtrace工具则通过生成日志文件记录内存分配和释放情况，便于追踪内存泄漏。

具体实现内存泄漏检测组件时，可以使用memleak.c文件并生成memleak可执行文件。

通过实验，我们能够验证内存泄漏检测功能，并根据结果定位到问题代码行。

对于mtrace工具的使用，通过设置MALLOC_TRACE环境变量和生成日志文件，能够记录内存分配与释放的详细情况，辅助分析内存泄漏问题。

总的来说，实现内存泄漏检测组件的目的是为了提高代码质量，确保程序稳定运行。

推荐使用宏定义方式实现内存泄漏检测组件，因其简洁且易于维护。

同时，mtrace工具提供了一种便捷的检测内存泄漏的方法，有助于开发者快速定位问题。