blocks|key|197092|text|Valgrind可用于检测Ex1中提到的内存泄漏。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|197093|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)|code-block|syntax|javascript|197094|entityMap|0|LINK|mutability|MUTABLE|url|http://valgrind.org/docs/manual/faq.html^0|0|8|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

<a href="http://valgrind.org/docs/manual/faq.html" rel="nofollow">Valgrind</a> can be used to detect memory leaks mentioned in Ex1. 

<pre><code>e.g. 
#include&lt;stdio.h&gt; 
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)
</code></pre>

blocks|key|3515998|text|我不知道kmalloc+(而且我没有一个带有Coverity许可证的Linux系统来测试它)，但是Coverity可以很容易地用malloc检测到这种形式的泄漏。所以我怀疑kmalloc会给它带来麻烦。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3515999|如果它确实带来了麻烦，您可以随时提供kmalloc函数的用户模型，该模型只是对malloc函数进行包装，以便Coverity知道如何处理该函数。|3516000|entityMap^0|4|7|1S|6|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

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

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.

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

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

I know <code>Coverity</code> 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 <code>Coverity</code> or tools like <code>Sparse</code>?

<pre><code>Ex2:
void foo(void) {
 kmalloc(512, GFP_KERNEL);
}

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

 if (true)
 return;

 kfree(ptr)
}
</code></pre>

is there any static code analyzer which can catch this memory leak?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

这样的泄漏对于肉眼来说似乎太微不足道了，我认为静态代码分析工具应该能够发现它们。 Ex1: void foo(void) {    u32 *ptr = kmalloc(512, GFP_KERNEL);    ptr = (u32 *)0xffffffff;    kfree(ptr); }我知道Coverity可以...

问有没有静态代码分析器可以捕捉到这个内存泄漏？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问有没有静态代码分析器可以捕捉到这个内存泄漏？EN