SAST应用安全静态分析开发工具代码质量【免费下载链接】semgrepLightweight static analysis for many languages. Find bug variants with patterns that look like source code.项目地址https://gitcode.com/GitHub_Trending/se/semgrep点击查看免费下载本篇文章以 semgrep 仓库中 tests/rules_error_recovery/README.md 为核心文档系统讲解 semgrep 针对目标文件在解析或运行阶段出错、但扫描仍须继续并产出匹配结果这一场景的专项测试体系。你将理解为什么这些测试不能放进常规的tests/rules/目录、tree-sitter 错误恢复如何产生超出文件实际行数的伪行号以及这类越界访问缺陷最终如何通过UFile.lines_of_file()的错误管理得以修复——并获得可直接运行的测试用例与验证方法。一、这个目录测试什么出错后仍要恢复并找到匹配原文档的核心界定非常清晰tests/rules_error_recovery/存放的是一类运行期必然触发错误的测试——例如某些目标文件在解析时会产生解析错误parsing error——但 semgrep 必须依然能从错误中恢复recover并找到匹配。换句话说这些测试验证的不是解析一切正常的理想路径而是部分失败的容错路径目标文件本身含有无法被完整解析的语法lines_of_file_outofbound.tf就是一个典型解析器tree-sitter通过错误恢复机制产出带缺陷的 ASTsemgrep 核心引擎依然可以基于可解析的部分执行模式匹配后续的 nosemgrep 行级分析与lines报告等环节不得因此崩溃。为什么不能放进tests/rules/原文档给出了明确理由常规的tests/rules/目录对测试要求更严格那里不允许目标文件出现诸如部分解析partial parsing之类的任何错误。也就是说We cant put those tests in../rules/because there we are more strict and ensure that there are no error such as partial parsing of targets.所以错误恢复类测试被单独隔离到本目录形成严格区与容错区两级测试体系前者保证规则在干净目标上的正确性后者专门守护 semgrep 在真实世界脏数据下的健壮性。这一点也呼应了仓库中src/core/Core_result.ml里以partial_profiling命名的逐文件匹配结果结构src/core/Core_result.ml从引擎数据模型层面承认了部分失败是扫描的常态之一。二、测试用例全解析lines_of_file_outofbound本目录目前包含一对完整的规则 目标文件测试lines_of_file_outofbound.yaml与lines_of_file_outofbound.tf。这对测试的命名直接揭示了它守护的缺陷——读取文件行时发生数组越界out-of-bound。2.1 目标文件故意制造解析错误lines_of_file_outofbound.tf 是一个 HCLTerraform文件其文件头注释完整交代了 bug 产生的链路# On this target file, we get some parse errors on the bar field # and tree-sitter error recovery insert some special tokens at the end # that have a line number above the actual number of lines in the file # (probably because it gets the line of the EOF token). This in turn # used to create some crash of semgrep and out-of-bound array access # for the nosemgrep analysis and the lines: report in the core_output. # This was fixed by having better error management around # the UFile.lines_of_file() function (hence the name of this test)文件正文是一个未加密的 DynamoDB 表资源定义resource aws_dynamodb_table grants { tags { bar ${var.environment} baz ${var.bar_tag} } }注意tags块内的bar字段写法会在 HCL 解析时产生解析错误这正是本测试刻意保留的脏目标。2.2 规则文件标准的 yaml 规则lines_of_file_outofbound.yaml 是一条结构完整的 semgrep 规则用于检出未开启服务端加密的 DynamoDB 表rules: - id: aws-dynamodb-table-unencrypted patterns: - pattern: | resource aws_dynamodb_table $ANYTHING { ... } - pattern-not-inside: | resource aws_dynamodb_table $ANYTHING { ... server_side_encryption { enabled true kms_key_arn ... } ... } message: messsage languages: [hcl] severity: WARNING该规则使用了两段式patterns组合pattern匹配任何aws_dynamodb_table资源块pattern-not-inside排除掉已经配置了server_side_encryption含enabled true与kms_key_arn的合法场景。languages: [hcl]指定目标语言severity: WARNING声明告警级别。即使目标文件存在解析错误这条规则也应当匹配到resource aws_dynamodb_table grants块并正常产出带lines信息的核心输出core_output。2.3 缺陷根因EOF 令牌的幽灵行号从目标文件头注释可以完整还原当时崩溃的机理共四步tree-sitter 错误恢复解析器在bar字段处遭遇语法错误后进入错误恢复流程会在文件末尾插入一些特殊令牌special tokens幽灵行号这些插入令牌的行号取自 EOF 令牌因此可能大于文件实际行数越界访问当引擎针对匹配结果做 nosemgrep 分析与lines报告时会按这些超界行号去读取文件行数组导致out-of-bound array access崩溃修复通过对UFile.lines_of_file()调用点加强错误管理将越界转为可处理的错误返回值从而让扫描继续而非崩溃。三、修复落点UFile.lines_of_file 的容错设计修复的核心位于 libs/commons/UFile.ml 的lines_of_file函数。其签名与行为如下let lines_of_file (start_line, end_line) (file : Fpath.t) : (string list, string) result let arr cat_array file in if not (start_line end_line) then Error (spf lines_of_file: start line %d end line %d for %s start_line end_line !!file) else let line_idx List_.enum start_line end_line in match arr with | [| |] - Ok [] (* 空文件特例 *) | _ - ( try Ok (line_idx | List.map (fun i - try arr.(i) with | Invalid_argument s - raise (Invalid_argument (spf %s on index %d s i)))) with | Invalid_argument s - Error (spf lines_of_file: %s s))这段实现体现了三层防线前置校验若start_line end_line直接返回Error不做数组访问越界捕获通过List_.enum start_line end_line枚举行号并逐个索引数组任何Invalid_argument越界异常都会被捕获并携带具体的index信息重新抛出统一收敛为 result 类型最终将越界情况包装为Error返回而接口类型(string list, string) result见 libs/commons/UFile.mli强制调用方显式处理失败杜绝野崩溃。设计者还在注释中明确表达了意图故意不提供抛异常的lines_of_file_exn便捷变体而是强制调用方妥善处理越界错误注释中给出的备选实现被保留为注释这正是本测试所守护的设计决策。四、错误恢复背后的两个关键机制4.1 nosemgrep 行级分析lines报告与 nosemgrep 分析是触发本次越界崩溃的两条消费链路。nosemgrep 是 semgrep 的内联忽略机制用户可以在命中行附近书写// nosemgrep或# nosemgrep注释来抑制误报。该机制在 cli/src/semgrep/constants.py 中有系统的说明与示例例如# nosemgrep: example-pattern-id hello(); // nosemgrep由于 nosemgrep 判断需要定位命中行上下文中是否存在忽略注释它天然依赖按行号读取文件内容的lines_of_file一旦行号来自 EOF 幽灵令牌而超出文件实际长度就必然触发越界——这就是错误恢复令牌导致 nosemgrep 分析崩溃的直接因果。4.2 部分解析与可恢复错误的分类从更大的视角看错误恢复是 semgrep 全链路的设计原则之一引擎侧用partial_profilingsrc/core/Core_result.ml承载部分失败的逐文件匹配结果规则侧对可恢复错误recoverable与不可恢复错误走不同代码路径参见 cli/tests/default/e2e/test_rule_parser.py 对Rule.invalid_rule_error归类为 recoverable 的说明目标文件解析侧则允许出现解析错误但继续扫描——这正是本目录测试所验证的行为。五、如何运行与验证这套测试5.1 测试运行方式错误恢复测试属于 semgrep-core 测试体系。根据 tests/README.md 的说明在仓库根目录执行make core-test可编译并运行全部 core 测试也可直接运行测试主程序./test并通过./test -s 字符串按名称筛选例如./test -s php只跑含php的用例./test不会自动重编译适合在仅修改.sgrep规则与目标文件时快速迭代。对于本目录可以使用./test -s lines_of_file_outofbound之类的方式单独定位该用例进行验证。5.2 断言约定semgrep-core 测试的目标文件通过ruleid:/MATCH:/ERROR:等标记行声明预期参见 tests/README.md。本测试的目标文件顶部使用# ruleid: aws-dynamodb-table-unencrypted声明即使文件中存在解析错误这条规则仍必须命中对应资源块。若扫描在该文件上崩溃或未产出匹配测试即失败——这正是对错误恢复 不越界 仍匹配三重预期的固化。六、从专项测试到工程启示回顾整个测试设计可以提炼出三点可复用的工程经验把脏数据变成一等公民专门的rules_error_recovery目录意味着错误恢复不是偶然发生的边界情况而是需要被持续回归守护的核心能力缺陷的命名即文档lines_of_file_outofbound让任何后来者仅凭目录名与文件名即可回溯到UFile.lines_of_file()的越界缺陷及其修复测试与源码之间形成可检索的对应关系错误管理优于异常蔓延将数组越界等底层异常在边界处捕获并收敛为result类型返回值libs/commons/UFile.ml让上层调用方nosemgrep 分析、lines报告可以优雅降级而非整体崩溃是 semgrep 在部分失败场景下保持扫描完成率的关键手段。对于需要为 semgrep 编写或扩充规则的开发者本目录也是一个重要提醒规则可以照常匹配那些不太干净的目标文件但前提是引擎层的错误恢复与行号处理足够健壮——而这正是tests/rules_error_recovery/持续守护的底线。赞分享SAST应用安全静态分析开发工具代码质量【免费下载链接】semgrepLightweight static analysis for many languages. Find bug variants with patterns that look like source code.项目地址https://gitcode.com/GitHub_Trending/se/semgrep点击查看免费下载相关推荐终极指南如何利用Dio实现强大的错误恢复机制与智能重试策略终极指南如何利用Dio实现强大的错误恢复机制与智能重试策略 在网络请求中错误和中断是常见现象。Dio作为Flutter生态中最流行的HTTP客户端提供了强网络后端WebSocketDocling 表格误标为图片缺陷的回归修复解读以 table_mislabeled_as_picture groundtruth 为例Docling 表格误标为图片缺陷的回归修复解读以 table_mislabeled_as_picture groundtruth 为例 Docling 的AI 应用计算机视觉OCREnzyme测试组件错误边界错误恢复测试Enzyme测试组件错误边界错误恢复测试 在React应用开发中错误边界Error Boundary是一种重要的组件用于捕获并处理子组件树中的Java测试前端上一篇BetterNCM安装器网易云音乐PC端插件一键管理工具终极指南下一篇BetterNCM安装器终极指南网易云音乐插件一键安装管理完全教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
semgrep 错误恢复（Error Recovery）测试机制解析：以 lines_of_file 越界缺陷修复为例
SAST应用安全静态分析开发工具代码质量【免费下载链接】semgrepLightweight static analysis for many languages. Find bug variants with patterns that look like source code.项目地址https://gitcode.com/GitHub_Trending/se/semgrep点击查看免费下载本篇文章以 semgrep 仓库中 tests/rules_error_recovery/README.md 为核心文档系统讲解 semgrep 针对目标文件在解析或运行阶段出错、但扫描仍须继续并产出匹配结果这一场景的专项测试体系。你将理解为什么这些测试不能放进常规的tests/rules/目录、tree-sitter 错误恢复如何产生超出文件实际行数的伪行号以及这类越界访问缺陷最终如何通过UFile.lines_of_file()的错误管理得以修复——并获得可直接运行的测试用例与验证方法。一、这个目录测试什么出错后仍要恢复并找到匹配原文档的核心界定非常清晰tests/rules_error_recovery/存放的是一类运行期必然触发错误的测试——例如某些目标文件在解析时会产生解析错误parsing error——但 semgrep 必须依然能从错误中恢复recover并找到匹配。换句话说这些测试验证的不是解析一切正常的理想路径而是部分失败的容错路径目标文件本身含有无法被完整解析的语法lines_of_file_outofbound.tf就是一个典型解析器tree-sitter通过错误恢复机制产出带缺陷的 ASTsemgrep 核心引擎依然可以基于可解析的部分执行模式匹配后续的 nosemgrep 行级分析与lines报告等环节不得因此崩溃。为什么不能放进tests/rules/原文档给出了明确理由常规的tests/rules/目录对测试要求更严格那里不允许目标文件出现诸如部分解析partial parsing之类的任何错误。也就是说We cant put those tests in../rules/because there we are more strict and ensure that there are no error such as partial parsing of targets.所以错误恢复类测试被单独隔离到本目录形成严格区与容错区两级测试体系前者保证规则在干净目标上的正确性后者专门守护 semgrep 在真实世界脏数据下的健壮性。这一点也呼应了仓库中src/core/Core_result.ml里以partial_profiling命名的逐文件匹配结果结构src/core/Core_result.ml从引擎数据模型层面承认了部分失败是扫描的常态之一。二、测试用例全解析lines_of_file_outofbound本目录目前包含一对完整的规则 目标文件测试lines_of_file_outofbound.yaml与lines_of_file_outofbound.tf。这对测试的命名直接揭示了它守护的缺陷——读取文件行时发生数组越界out-of-bound。2.1 目标文件故意制造解析错误lines_of_file_outofbound.tf 是一个 HCLTerraform文件其文件头注释完整交代了 bug 产生的链路# On this target file, we get some parse errors on the bar field # and tree-sitter error recovery insert some special tokens at the end # that have a line number above the actual number of lines in the file # (probably because it gets the line of the EOF token). This in turn # used to create some crash of semgrep and out-of-bound array access # for the nosemgrep analysis and the lines: report in the core_output. # This was fixed by having better error management around # the UFile.lines_of_file() function (hence the name of this test)文件正文是一个未加密的 DynamoDB 表资源定义resource aws_dynamodb_table grants { tags { bar ${var.environment} baz ${var.bar_tag} } }注意tags块内的bar字段写法会在 HCL 解析时产生解析错误这正是本测试刻意保留的脏目标。2.2 规则文件标准的 yaml 规则lines_of_file_outofbound.yaml 是一条结构完整的 semgrep 规则用于检出未开启服务端加密的 DynamoDB 表rules: - id: aws-dynamodb-table-unencrypted patterns: - pattern: | resource aws_dynamodb_table $ANYTHING { ... } - pattern-not-inside: | resource aws_dynamodb_table $ANYTHING { ... server_side_encryption { enabled true kms_key_arn ... } ... } message: messsage languages: [hcl] severity: WARNING该规则使用了两段式patterns组合pattern匹配任何aws_dynamodb_table资源块pattern-not-inside排除掉已经配置了server_side_encryption含enabled true与kms_key_arn的合法场景。languages: [hcl]指定目标语言severity: WARNING声明告警级别。即使目标文件存在解析错误这条规则也应当匹配到resource aws_dynamodb_table grants块并正常产出带lines信息的核心输出core_output。2.3 缺陷根因EOF 令牌的幽灵行号从目标文件头注释可以完整还原当时崩溃的机理共四步tree-sitter 错误恢复解析器在bar字段处遭遇语法错误后进入错误恢复流程会在文件末尾插入一些特殊令牌special tokens幽灵行号这些插入令牌的行号取自 EOF 令牌因此可能大于文件实际行数越界访问当引擎针对匹配结果做 nosemgrep 分析与lines报告时会按这些超界行号去读取文件行数组导致out-of-bound array access崩溃修复通过对UFile.lines_of_file()调用点加强错误管理将越界转为可处理的错误返回值从而让扫描继续而非崩溃。三、修复落点UFile.lines_of_file 的容错设计修复的核心位于 libs/commons/UFile.ml 的lines_of_file函数。其签名与行为如下let lines_of_file (start_line, end_line) (file : Fpath.t) : (string list, string) result let arr cat_array file in if not (start_line end_line) then Error (spf lines_of_file: start line %d end line %d for %s start_line end_line !!file) else let line_idx List_.enum start_line end_line in match arr with | [| |] - Ok [] (* 空文件特例 *) | _ - ( try Ok (line_idx | List.map (fun i - try arr.(i) with | Invalid_argument s - raise (Invalid_argument (spf %s on index %d s i)))) with | Invalid_argument s - Error (spf lines_of_file: %s s))这段实现体现了三层防线前置校验若start_line end_line直接返回Error不做数组访问越界捕获通过List_.enum start_line end_line枚举行号并逐个索引数组任何Invalid_argument越界异常都会被捕获并携带具体的index信息重新抛出统一收敛为 result 类型最终将越界情况包装为Error返回而接口类型(string list, string) result见 libs/commons/UFile.mli强制调用方显式处理失败杜绝野崩溃。设计者还在注释中明确表达了意图故意不提供抛异常的lines_of_file_exn便捷变体而是强制调用方妥善处理越界错误注释中给出的备选实现被保留为注释这正是本测试所守护的设计决策。四、错误恢复背后的两个关键机制4.1 nosemgrep 行级分析lines报告与 nosemgrep 分析是触发本次越界崩溃的两条消费链路。nosemgrep 是 semgrep 的内联忽略机制用户可以在命中行附近书写// nosemgrep或# nosemgrep注释来抑制误报。该机制在 cli/src/semgrep/constants.py 中有系统的说明与示例例如# nosemgrep: example-pattern-id hello(); // nosemgrep由于 nosemgrep 判断需要定位命中行上下文中是否存在忽略注释它天然依赖按行号读取文件内容的lines_of_file一旦行号来自 EOF 幽灵令牌而超出文件实际长度就必然触发越界——这就是错误恢复令牌导致 nosemgrep 分析崩溃的直接因果。4.2 部分解析与可恢复错误的分类从更大的视角看错误恢复是 semgrep 全链路的设计原则之一引擎侧用partial_profilingsrc/core/Core_result.ml承载部分失败的逐文件匹配结果规则侧对可恢复错误recoverable与不可恢复错误走不同代码路径参见 cli/tests/default/e2e/test_rule_parser.py 对Rule.invalid_rule_error归类为 recoverable 的说明目标文件解析侧则允许出现解析错误但继续扫描——这正是本目录测试所验证的行为。五、如何运行与验证这套测试5.1 测试运行方式错误恢复测试属于 semgrep-core 测试体系。根据 tests/README.md 的说明在仓库根目录执行make core-test可编译并运行全部 core 测试也可直接运行测试主程序./test并通过./test -s 字符串按名称筛选例如./test -s php只跑含php的用例./test不会自动重编译适合在仅修改.sgrep规则与目标文件时快速迭代。对于本目录可以使用./test -s lines_of_file_outofbound之类的方式单独定位该用例进行验证。5.2 断言约定semgrep-core 测试的目标文件通过ruleid:/MATCH:/ERROR:等标记行声明预期参见 tests/README.md。本测试的目标文件顶部使用# ruleid: aws-dynamodb-table-unencrypted声明即使文件中存在解析错误这条规则仍必须命中对应资源块。若扫描在该文件上崩溃或未产出匹配测试即失败——这正是对错误恢复 不越界 仍匹配三重预期的固化。六、从专项测试到工程启示回顾整个测试设计可以提炼出三点可复用的工程经验把脏数据变成一等公民专门的rules_error_recovery目录意味着错误恢复不是偶然发生的边界情况而是需要被持续回归守护的核心能力缺陷的命名即文档lines_of_file_outofbound让任何后来者仅凭目录名与文件名即可回溯到UFile.lines_of_file()的越界缺陷及其修复测试与源码之间形成可检索的对应关系错误管理优于异常蔓延将数组越界等底层异常在边界处捕获并收敛为result类型返回值libs/commons/UFile.ml让上层调用方nosemgrep 分析、lines报告可以优雅降级而非整体崩溃是 semgrep 在部分失败场景下保持扫描完成率的关键手段。对于需要为 semgrep 编写或扩充规则的开发者本目录也是一个重要提醒规则可以照常匹配那些不太干净的目标文件但前提是引擎层的错误恢复与行号处理足够健壮——而这正是tests/rules_error_recovery/持续守护的底线。赞分享SAST应用安全静态分析开发工具代码质量【免费下载链接】semgrepLightweight static analysis for many languages. Find bug variants with patterns that look like source code.项目地址https://gitcode.com/GitHub_Trending/se/semgrep点击查看免费下载相关推荐终极指南如何利用Dio实现强大的错误恢复机制与智能重试策略终极指南如何利用Dio实现强大的错误恢复机制与智能重试策略 在网络请求中错误和中断是常见现象。Dio作为Flutter生态中最流行的HTTP客户端提供了强网络后端WebSocketDocling 表格误标为图片缺陷的回归修复解读以 table_mislabeled_as_picture groundtruth 为例Docling 表格误标为图片缺陷的回归修复解读以 table_mislabeled_as_picture groundtruth 为例 Docling 的AI 应用计算机视觉OCREnzyme测试组件错误边界错误恢复测试Enzyme测试组件错误边界错误恢复测试 在React应用开发中错误边界Error Boundary是一种重要的组件用于捕获并处理子组件树中的Java测试前端上一篇BetterNCM安装器网易云音乐PC端插件一键管理工具终极指南下一篇BetterNCM安装器终极指南网易云音乐插件一键安装管理完全教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
