一个函数打开文件，正常读完后会关闭它，但读取失败时可能直接返回。这样的代码平时能跑通，只有错误分支反复执行时，才容易暴露文件句柄持续占用的问题。Coverity可以在静态分析中追踪资源的获取、传递和释放，并标出一条可能发生泄漏的路径。以C/C++项目为例，查看这类告警时，既要看资源在哪里取得，也要看程序沿哪条分支走到了退出位置。

　　一、Coverity怎么查资源泄漏

　　已经有扫描结果的项目，可以在Coverity Connect中按检查器筛选。需要自己跑一次分析时，则要先确保目标文件参与了构建捕获，否则结果里可能根本没有分析这段代码。

　　1、在Coverity Connect中筛选告警

　　①在Coverity Connect的【项目】（Projects）页面打开目标项目，进入【问题】（Issues）列表，核对当前分支对应的分析流和快照。

　　②在新版界面点击【添加筛选器】（Add filters），用【Checker】筛选【RESOURCE_LEAK】。如果已有其他筛选条件，检查它们是否排除了目标文件或已分类的问题。

　　③点击列表中的【CID】，进入缺陷详情，核对文件、函数和检查器名称，再查看源码旁的事件路径。

　　同一个CID可能有多次出现记录。排查某次提交时，分析快照比列表中的文件行号更值得先核对。否则，手头代码虽然已经改过，看到的仍可能是较早一次扫描记录下来的路径。

　　2、从构建捕获开始检查C/C++项目

　　下面以已配置好Coverity编译器、使用GNU Make构建的项目为例。已有持续集成任务时，可以沿用该任务的构建目标和分析配置。

　　①在项目构建目录运行【cov-build--dir cov-int make-B】，将捕获结果写入【cov-int】。

　　②查看【cov-int/build-log.txt】，确认目标源文件参与了编译，并检查有无捕获或解析失败。

　　③运行【cov-analyze--dir cov-int--enable RESOURCE_LEAK】，再查看【cov-int/output/analysis-log.txt】，核对分析是否完成及检查器的运行情况。

　　④按项目已有流程用【cov-commit-defects】把结果提交到对应分析流，在【问题】列表筛选【RESOURCE_LEAK】。

　　二、Coverity资源泄漏告警怎么看

　　告警常落在函数返回或变量离开作用域的位置。那一行表示分析器在这条路径上发现资源仍未释放，实际漏掉的清理动作可能在更早的条件分支里。

　　1、从资源获取事件确认追踪对象

　　①在【CID】详情的事件路径中回到资源获取处，找到对应的函数调用和接收返回值的变量。

　　②如果路径从【malloc】开始，记录被追踪的指针，检查后续应由哪里调用【free】。如果路径从【fopen】开始，则记录文件指针，并寻找对应的【fclose】。

　　③沿事件顺序查看资源是否被赋给另一个变量、传给其他函数，或交给负责清理的对象。存在封装时，打开相应函数的实现，核对它接管资源的条件。

　　判断时要跟住同一份资源。一个函数里打开两个文件，即使其中一个调用了关闭函数，也要确认关闭的就是告警所指的那个文件。

　　2、沿分支找到漏掉释放的出口

　　以读取配置文件为例，程序成功打开文件后，可能在解析失败时提前返回。正常路径末尾的关闭操作，在这条失败路径上就不会执行。

　　①在【CID】详情中按顺序查看条件事件，记录每次判断走的是哪个分支。

　　②从【fopen】成功后的分支跟到告警标出的【return】，检查中途是否经过对应的【fclose】，或者是否进入了统一清理代码。

　　③把告警路径与正常返回路径对照，找出两条路径从哪里分开，确认是哪个错误出口跳过了清理。

　　3、确认释放责任是否已经转移

　　①如果告警路径中有跨函数调用，打开对应实现，核对调用成功和失败时分别由哪一方释放资源。

　　②检查是否存在析构函数、统一清理函数或外部库负责释放。把相关源码或接口约定与【CID】事件逐项对照。

　　③如果清理确实存在，但分析路径没有反映出来，在缺陷备注中记录调用链和释放依据，再检查相关实现是否被本次分析捕获。

　　资源交给另一个函数后，释放责任可能只在调用成功时转移。举例来说，注册接口成功后由管理器关闭句柄，注册失败时仍由调用方关闭。只看到资源被传了出去，还不足以判断错误分支已经完成清理。

　　三、Coverity资源泄漏修复后怎么复查

　　修复时应补上告警路径缺失的清理，同时检查其他路径是否已经释放过同一资源。重新扫描时，构建范围和分析流也要能与原结果对应。

　　1、补齐失败分支的清理

　　①打开【CID】所指函数，找到资源获取成功后的错误出口，确认此时资源仍归当前函数管理。

　　②对已成功打开的文件，在该错误出口返回前调用【fclose】，或将该分支接入已有的统一清理代码。

　　③分别核对打开失败、解析失败和正常结束三条路径，确认每次成功获取的文件句柄都会在应当关闭时关闭一次。

　　如果多个分支共用清理代码，还要确认部分初始化的情况。例如，函数先打开文件，再分配缓冲区，分配失败时应关闭已经打开的文件。清理代码要根据各项资源是否获取成功，分别决定是否释放。

　　2、在新快照中核对原告警

　　①用修复后的提交重新执行【cov-build】和【cov-analyze】，保留原扫描的构建目标与相关检查器配置。

　　②将结果提交到同一分析流，在【问题】列表中选择新快照，按原【CID】核对结果，并按文件和【RESOURCE_LEAK】检查是否还有同类告警。

　　③如果原告警在新快照中不再出现，查看【build-log.txt】确认目标文件仍被捕获，再记录修复提交和复查结果。

　　总结

　　Coverity的事件路径适合用来回答一个具体问题：资源成功获取以后，在什么条件下走到了没有清理的出口。评审时把触发条件、释放责任和代码位置一起写清楚，开发人员就能判断该补清理分支，还是核对封装函数的接管约定。对反复出现同类告警的模块，这些记录也能帮助团队统一错误处理方式。