解读dmesg日志中的内存泄漏信息

在日常排查Linux系统问题时，dmesg是一个绕不开的工具——它的全称是“display message”或“driver message”，专门用来展示内核的启动信息和运行时状态。说白了，它就是内核的“日记本”，记录着硬件状态、驱动程序行为，以及各种系统事件。而在这本日记里，有时候也会出现关于内存泄漏的蛛丝马迹。

先简单说说什么是内存泄漏：程序向系统申请了一块内存，用完之后却不归还，一次又一次地申请，最终把系统内存掏空。在Linux环境下，内存泄漏的源头可能是内核模块、驱动程序，也可能是某个应用程序。

那么，如何从dmesg日志里揪出这些泄漏信息？关键是要盯住几个关键词：

• “leak”——直接告诉你泄漏发生了。
• “kmalloc” 或 “kfree”——内核内存分配和释放的函数，它们成对出现才算正常。
• 内存地址——泄漏具体发生在哪个位置。
• 模块或驱动名称——谁搞的鬼，一目了然。

举个例子，下面这段dmesg日志片段就非常典型：

[ 12345.678901] [ERROR] my_driver: Memory leak detected at address 0x7fff12345678
[ 12345.678902] [ERROR] my_driver: Failed to free memory at address 0x7fff12345678
[ 12345.678903] [ERROR] my_driver: Please check your code for memory management issues.

从这段日志里，我们可以迅速锁定两个关键点：

• 泄漏发生在地址 0x7fff12345678。
• 肇事模块是 my_driver。

接下来的处理思路就很明确了：去翻my_driver模块的源代码，找到那些申请内存却忘记释放的地方。特别要检查kmalloc和kfree是否成对出现——每次分配内存，都必须有对应的释放操作，这是内核编程里最基本也最容易出错的规矩。