第3章静态代码分析

3. 静态代码分析：用Clang Static Analyzer和Cppcheck做源码级泄漏预检

说到内存泄漏检测，很多人第一反应就是跑Valgrind。但说实话，Valgrind是运行时工具，你得把代码编译好、跑起来、触发到那条路径才能发现问题。我个人的习惯是——在编译之前，先用静态分析工具扫一遍。这就像写文章之前先列个提纲，很多低级错误在提纲阶段就能发现。

静态代码分析，说白了就是让工具帮你读代码。它不运行程序，只靠分析语法树和控制流图来找出潜在问题。对于MTK8676这种座舱芯片，代码量动辄几百万行，靠人眼review根本看不过来。这时候，Clang Static Analyzer和Cppcheck就是你的左膀右臂。

3.1 Clang Static Analyzer：苹果家的看门狗

Clang Static Analyzer（简称CSA）是LLVM/Clang工具链自带的静态分析器。它最擅长的事情就是——追踪资源分配和释放的路径。你想想看，一个malloc出来的指针，经过if-else、循环、函数调用，最后有没有被free掉？CSA会一条条路径帮你走完。

我在MTK8676的项目中遇到过这样一个案例：一个音频流处理函数，在正常路径下会释放DMA缓冲区，但异常路径里直接return了，忘了释放。CSA一下子就标出来了，还画出了控制流图。说实话，要是靠人工review，这种藏在三层嵌套if里的问题，真不一定能发现。

使用CSA很简单，你只需要在编译时加上几个flag：

# 使用scan-build工具包装编译命令
scan-build gcc -c audio_stream.c -o audio_stream.o

# 或者直接调用clang的静态分析
clang --analyze audio_stream.c -o audio_stream.plist

CSA会生成一个.plist文件，里面包含了所有发现的问题。我个人习惯用scan-view来查看结果，它会启动一个本地Web服务器，用浏览器打开，界面很直观。

CSA能检测的内存泄漏类型：

直接泄漏：malloc后没有free，指针丢失
间接泄漏：结构体嵌套分配，外层释放了但内层没释放
条件泄漏：某些分支释放了，某些分支没释放
循环泄漏：循环体内分配内存，但只释放了最后一次

不过CSA也有个缺点——慢。全量分析一次MTK8676的代码库，可能要跑好几个小时。所以我建议你只在关键模块上跑，比如音频、视频、通信协议栈这些容易出问题的部分。

3.2 Cppcheck：轻量级的守门员

如果说CSA是重型火炮，那Cppcheck就是一把轻便的手枪。它不需要编译环境，直接分析源代码文件，速度飞快。我经常在写完一个函数后，顺手跑一下Cppcheck，就像写完一段话后检查一下错别字。

Cppcheck的检测规则比CSA更丰富，它不光查内存泄漏，还能查数组越界、空指针解引用、未初始化变量等等。对于MTK8676这种嵌入式系统，这些检查都很有价值。

# 基本用法
cppcheck --enable=all audio_stream.c

# 输出到文件
cppcheck --enable=warning,performance --xml audio_stream.c 2> report.xml

# 针对嵌入式平台的检查
cppcheck --platform=arm64-windows --enable=all audio_stream.c

我记得有一次，Cppcheck帮我发现了一个很隐蔽的问题：一个函数里用strdup复制了字符串，但函数返回前没有free。这个函数被调用了上千次，每次泄漏几十个字节，日积月累就是个大问题。嗯，这种问题Valgrind也能发现，但Cppcheck在编译前就报出来了，省了我不少调试时间。

我的使用技巧：

把Cppcheck集成到CI流水线中，每次提交代码自动跑一遍
使用--suppress选项过滤掉已知的误报，比如第三方库的代码
结合--inconclusive选项，让Cppcheck报告一些不太确定但值得关注的问题

3.3 两个工具的对比与配合

你可能会问：这两个工具到底选哪个？我的答案是——都要用。它们各有侧重，配合起来效果最好。

特性	Clang Static Analyzer	Cppcheck
分析深度	路径敏感，能跨函数追踪	路径不敏感，主要做模式匹配
分析速度	慢（需要编译）	快（直接分析源码）
检测范围	内存泄漏、空指针、资源泄漏	内存泄漏、数组越界、未初始化、风格问题
误报率	较低	较高（需要配置过滤）
适用场景	关键模块的深度分析	日常开发中的快速检查

我个人的工作流是这样的：

日常开发：写完代码后，先跑Cppcheck，快速扫一遍明显问题
代码审查前：对修改的模块跑CSA，做一次深度分析
版本发布前：全量跑CSA，生成最终报告

曾经踩过的坑：

我曾经完全依赖静态分析工具，觉得跑过了就万事大吉。结果有一次，CSA和Cppcheck都没报错，但程序跑起来还是泄漏了。后来发现，问题出在动态加载的共享库上——静态分析工具看不到动态链接的代码。所以，静态分析只是第一道防线，不能替代运行时检测。

3.4 实战：在MTK8676上配置静态分析

好了，理论说完了，咱们来点实际的。在MTK8676的Android系统上配置静态分析，有几个需要注意的地方。

首先，MTK8676的代码是交叉编译的，目标平台是ARM64。CSA需要知道目标平台的头文件和库路径，否则会报一堆找不到头文件的错误。

# 设置交叉编译环境
export CC=aarch64-linux-android-clang
export CXX=aarch64-linux-android-clang++

# 使用scan-build时指定编译器
scan-build --use-cc=$CC --use-cxx=$CXX make -j8

其次，MTK的代码里有很多宏定义和条件编译，静态分析工具可能不理解这些宏。我建议你在分析时加上-D参数，把关键的宏定义传进去。

# 传递宏定义
cppcheck -DMTK_PLATFORM -DANDROID --enable=all audio_stream.c

最后，别忘了分析头文件。很多内存泄漏的根源在头文件里定义的宏或内联函数。CSA默认只分析.c/.cpp文件，你可以用--analyze-headers选项让它也分析头文件。

# 分析头文件
clang --analyze --analyze-headers audio_stream.c

说实话，配置这些环境确实有点繁琐，但一旦配好了，后面就是一劳永逸的事情。我建议你把配置脚本写成一个Makefile或者shell脚本，每次分析时直接运行就行。