【问题标题】:Analyzing kmemleak result分析 kmemleak 结果
【发布时间】:2023-03-30 22:28:02
【问题描述】:

我正在我的一个模块上运行 kmemleak 以查找泄漏,下面是一段时间后的结果。 从结果来看,我理解的是下面的地址是 .ko 或 .o 文件中的对象/s 地址。

unreferenced object 0xffff8803c9708f10 (size 32):
  comm "resiter_access_i_o", pid 2320, jiffies 4294798486
  hex dump (first 32 bytes):
    d8 8e 70 c9 03 88 ff ff a0 8e 70 c9 03 88 ff ff  ..p.......p.....
    68 8e 70 c9 03 88 ff ff 30 8e 70 c9 03 88 ff ff  h.p.....0.p.....
  backtrace:
    [<ffffffff81516e3e>] kmemleak_alloc+0x5e/0xd0
    [<ffffffff8117cf2a>] __kmalloc+0x1ea/0x330
    [<ffffffffa04cafbb>] 0xffffffffa04cafbb
    [<ffffffffa04ad3a0>] 0xffffffffa04ad3a0
    [<ffffffffa04ae8fb>] 0xffffffffa04ae8fb
    [<ffffffffa0422e3a>] 0xffffffffa0422e3a
    [<ffffffffa0423022>] 0xffffffffa0423022
    [<ffffffff81096e86>] kthread+0x96/0xa0
    [<ffffffff8100c20a>] child_rip+0xa/0x20
    [<ffffffffffffffff>] 0xffffffffffffffff

根据我的理解,我使用gdb做了以下查找对应的函数 但我收到以下错误

gdb resiter_access_i_o.ko
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from resiter_access_i_o.ko ...done.
(gdb) info symbol 0xffffffffa04ae8fb
No symbol matches 0xffffffffa04ae8fb.
(gdb) q

能否告诉我如何找出与上述地址对应的函数?提前谢谢...

【问题讨论】:

  • 当分配是由之后卸载的内核模块进行时,我已经看到了这样的事情。在 kmemleak 打印调用跟踪时,该模块已卸载并且其符号信息未知。假设它是您的模块,您可能知道每个部分的大小以及其中的代码,对吧? readelf 可能会有所帮助。然后你可以尝试猜测模块加载的位置(.init.**.text*区域的起始地址是0x1000的倍数)。
  • 或者,您可以尝试再次分析您的模块,但在卸载之前注意其加载部分的起始地址。请参见 /sys/module//sections/
    。当您从 kmemleak 获得泄漏报告时,您将能够确定调用函数的部分以及那里的偏移量。然后,可以使用objdump -dr 或 GDB 来查找调用了哪些函数。
  • 另一个机会仅限于 x86,但您似乎就是这种情况。如果内核是 2.6.32 或更新版本,您可以使用来自KEDR frameworkmemory leak detector。它在目标模块完全卸载之前确定调用堆栈和相关地址,因此受该问题的影响较小。
  • 感谢尤金的回复。我一定会看看 KEDR 框架并发布我的发现。

标签: memory memory-management memory-leaks linux-kernel linux-device-driver


【解决方案1】:

为什么不尝试对象转储、crashdum、crashtool 等工具呢? 您应该能够轻松地从这些工具和您拥有的对象中找到函数名称

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2022-08-12
    • 2021-08-23
    • 1970-01-01
    • 2021-08-19
    • 2016-03-12
    • 2015-09-30
    • 2012-12-24
    • 2021-10-26
    相关资源
    最近更新 更多