是否有任何静态代码分析器可以捕获此内存泄漏？

Such leaks seem too trivial to naked eye and I think static code analysis tools should be able to find them out.

这种泄漏似乎无法用肉眼观察,我认为静态代码分析工具应该能够找到它们。

 Ex1:
 void foo(void) {
    u32 *ptr = kmalloc(512, GFP_KERNEL);
    ptr = (u32 *)0xffffffff;
    kfree(ptr);
 }

I know Coverity can find leaks as below but not sure about the above one: Can anyone please let me know if this will get detected in either Coverity or tools like Sparse?

我知道Coverity可以发现如下泄漏,但不确定上述问题:任何人都可以告诉我这是否会在Coverity或Sparse等工具中被检测到?

Ex2:
void foo(void) {
    kmalloc(512, GFP_KERNEL);
}

Ex3:
void foo(void) {
    void * ptr = kmalloc(512, GFP_KERNEL);

    if (true)
        return;

    kfree(ptr)
}

2 个解决方案

#1

I don't know about kmalloc (and I don't have a Linux system with a Coverity license to test that on), but Coverity detects leaks of this form with malloc easily. So I doubt kmalloc would give it trouble.

我不知道kmalloc(我没有一个带有Coverity许可证的Linux系统来测试它),但Coverity很容易用malloc检测到这个表单的泄漏。所以我怀疑kmalloc会给它带来麻烦。

If it does give trouble, you can always provide a user model of the kmalloc function that just wraps around the malloc function so Coverity knows how to treat the function.

如果它确实给您带来了麻烦,您总是可以提供仅包含malloc函数的kmalloc函数的用户模型,以便Coverity知道如何处理该函数。

#2

-2

Valgrind can be used to detect memory leaks mentioned in Ex1.

Valgrind可用于检测Ex1中提到的内存泄漏。

e.g. 
#include<stdio.h> 
void foo(void) {
    int *ptr = (int *)malloc(512);
    ptr = (int *)0xffffffff;
    free(ptr);
 }
int main(){
        foo();
        return 1;
}

Valigrind Output:

[test@myhost /tmp]# valgrind --tool=memcheck --leak-check=full ./Ex1
==23780== Memcheck, a memory error detector
==23780== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==23780== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==23780== Command: ./Ex1
==23780== 
==23780== Invalid free() / delete / delete[]
==23780==    at 0x4A05A31: free (vg_replace_malloc.c:325)
==23780==    by 0x400509: foo (in /tmp/Ex1)
==23780==    by 0x400514: main (in /tmp/Ex1)
==23780==  Address 0xffffffff is not stack'd, malloc'd or (recently) free'd
==23780== 
==23780== 
==23780== HEAP SUMMARY:
==23780==     in use at exit: 512 bytes in 1 blocks
==23780==   total heap usage: 1 allocs, 1 frees, 512 bytes allocated
==23780== 
==23780== 512 bytes in 1 blocks are definitely lost in loss record 1 of 1
==23780==    at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==23780==    by 0x4004E9: foo (in /tmp/Ex1)
==23780==    by 0x400514: main (in /tmp/Ex1)
==23780== 
==23780== LEAK SUMMARY:
==23780==    definitely lost: 512 bytes in 1 blocks
==23780==    indirectly lost: 0 bytes in 0 blocks
==23780==      possibly lost: 0 bytes in 0 blocks
==23780==    still reachable: 0 bytes in 0 blocks
==23780==         suppressed: 0 bytes in 0 blocks
==23780== 
==23780== For counts of detected and suppressed errors, rerun with: -v
==23780== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)

#1