EDP Sciences logo
Submit your paper
Search
Menu
All issues Volume 43 / No 3 (June 2025) JNWPU, 43 3 (2025) 600-609 Full HTML
Open Access
Issue
JNWPU
Volume 43, Number 3, June 2025
Page(s) 600 - 609
DOI https://doi.org/10.1051/jnwpu/20254330600
Published online 11 August 2025

© 2025 Journal of Northwestern Polytechnical University. All rights reserved.

Licence Creative CommonsThis is an Open Access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

C语言因其使用灵活、执行效率高, 既具有高级语言的优势, 又具备低级语言的特点, 因此广泛应用于航空、航天、电气、交通等高度依赖安全关键软件的领域[1]。但是对于高安全、高可信的关键软件而言C语言程序缺少必要的安全措施, 例如对指针操作未进行严格限定、对数组和字符串未提供边界检查等, 易导致软件运行时出现难以发现的低概率异常, 造成灾难性的损失[2]。因此, 如何发现潜在运行时故障, 提高软件质量和可信性[3]已成为研究热点。近年来, 有关该课题的研究已经取得了巨大进步, 在诸多方法中, 软件监控技术(software monitoring technology)因其效果显著、应用广泛, 取得了许多重要成果。

软件监控技术可以节省开发和维护成本、提升开发效率并确保软件的可信性[4], 其主要分为构造时监控和运行时监控2类方法。构造时监控基于代码静态分析方法, 对正在构造程序的代码进行在线分析并及时给出故障反馈。随着软件规模和复杂度不断提高, 对尽早发现故障的需求日益增加, 因此构造软件时检测故障的监控技术被广泛研究。但现有研究所提出的相关技术可监控的故障范围较小或只面向某些特定故障, 软件构造过程中编写的代码片段, 因无法编译导致不能及时有效地检测故障。

本文所提出的任务安全关键软件构造时在线监控方法, 归纳了5类43种故障类型, 针对C代码以函数为单位代码量逐步增长的特点, 在构造C程序时对代码片段进行实时监控和静态分析, 能够全面、高效地检测潜在故障并反馈给开发人员, 从而提高软件安全性和可信性, 节省后续测试成本。本文贡献如下:

1) 针对在线编辑的C程序片段实时编译和测试问题, 提出了一种混合监控方法, 结合智能时间阈值和deepfix代码修复技术, 高效实现C程序构造时的可编译版本自动生成。

2) 为了全面有效地检测各类故障, 针对任务安全关键软件5类运行时故障产生条件归纳出43种故障类型, 基于抽象语法树建立在线编辑的C程序片段故障的规则库, 涵盖了断言违反、数组越界、多线程中的死锁和饥饿等多种故障类型。

3) 提出了一种基于规则库的语法结构匹配算法, 实现在线编辑的C程序片段故障监控。利用构建的规则库来匹配C程序的抽象语法树结构, 以识别潜在故障。算法通过递归遍历AST节点, 并根据规则库进行匹配, 能够识别包括违反断言、数组越界、空指针引用等在内的多种故障。

实验验证表明, 本文所提出的C程序构造时在线监控方法能够有效地识别出实验对象中的潜在故障, 具有较高的自动化程度, 适用于人机结对编程的进一步研究。

1 相关工作

对软件实施合理的监控, 可以及时获得软件系统的信息, 准确分析并判断软件是否处于可信状态。软件监控技术在软件开发、软件调优、软件实时容错以及软件维护方面得到了广泛应用。现有软件监控技术大致分为构造时监控和运行时监控两大类。前者在编码过程中通过代码片段静态分析识别潜在故障, 提高软件质量和开发效率; 后者在运行过程中实时分析、处理软件的状态信息, 可有效降低软件维护成本。随着计算机软件规模和复杂度的不断提高, 尽早发现故障的需求日益迫切, 因此在构造软件时检测故障的监控技术被广泛研究。

构造时监控是基于代码静态分析方法, 对正在构造程序的代码实时进行分析并及时给出相应反馈的技术。现有研究主要采用形式化方法、软件质量模型方法和机器学习方法。

基于形式化的方法主要有：Li等[4]实现了一种支持SOFL形式化工程方法的软件工具, 可以自动检查正在构建的形式化规范, 确保内部一致性。Wang等[5]提出了基于人机结对编程特定编程范式的框架, 该框架提供了故障建模的通用方法, 检测程序构建时潜在安全漏洞。针对不完整程序的静态分析方法, Schubert和Wang等[6-7]提出可以在编码阶段进行分析, 从而可以实时执行漏洞发现。Dai等[8]提出了结合风险编号和代码检查图的技术, 旨在提高程序员在编程过程中自我检查代码的效率和准确性。

基于软件质量的度量值及模型定义监控方法, 文献[9]提出一个基于软件开发过程数据的可视化质量监控工具, 该工具能够计算软件当前版本的度量值以反映产品质量的实时变化趋势。Ronchieri等[10]定义软件质量模型并设计用于监控软件质量的度量, 形成可在任何开发阶段预测软件质量的数学模型。Bielikova等[11]提出了一个独立于平台的代码监控环境, 该环境使用信息标签作为文档模型和用户模型之上的描述性元数据, 并支持多个软件开发监控工具。

基于机器学习的方法主要采用机器学习和人工智能算法提高代码检查的效率和精度。例如Allamanis等[12]基于神经网络建立了软件构造的监控系统, 其具有很强的识别软件故障的能力, 可将软件开发效率提高约20%, 但仅适用于大型软件系统的开发, 对于小型软件开发具有一定的局限性。Lal等[13]引入bug数据库, 提出一种基于机器学习的代码评审方法, 并在Eclipse上进行了可行性评估, 快速、清晰地检查构建中的代码。还有一些研究者利用生成式预训练Transformer(GPT)进行代码检查[14]。但这些研究主要侧重于检查完整的代码, 而不是帮助程序员在程序构造时检测代码。

目前, 国内外关于软件监控技术的研究, 其可监控的故障范围较小, 只面向某种故障, 例如Wang的基于人机结对编程特定编程范式框架无法处理程序中的嵌套结构; Dai的基于检查表的人机结对检查方法主要检测语义错误; Li的支持SOFL形式化工程方法的软件工具主要检测形式化规范内部一致性; Lal的基于机器学习的代码评审方法主要检测内存泄漏和逻辑错误。Georgsen的基于生成式预训练Transformer的代码检查主要检查完整代码, 而不是检查构造时的代码。

因此针对这些研究工作的不足之处, 本文提出的C程序构造时在线监控方法, 包括代码片段的可编译版本生成技术和基于规则库的C程序潜在故障的语法结构匹配方法, 可在构造过程中实时识别潜在的5类运行时故障。其中, 预识别C程序故障语法结构的规则库为检测其他高级语言程序构造时的潜在故障扩展了思路, 具有指导意义。

2 C程序构造时故障检测流程

为实现安全关键软件的构造时在线监控和故障检测, 首先要分析不同故障产生的条件及其表现形式。本文归纳了违反断言、数组越界、空指针引用、线程死锁和饥饿等5类运行时故障的特征, 定义了各自产生的条件, 划分了43种故障类型。

其次, 定义每一种故障类型的关键语句到抽象语法树结构的映射规则, 建立一个能够预识别潜在故障语法结构的规则库, 并设计相应的匹配算法以快速检测不同类型的故障。

然而, 抽象语法树的构建依赖于完整的、可编译的C代码, 这就需要在构造时能够将代码片段生成可编译的代码版本。本文采用混合监控机制, 基于事件触发和时间阈值相结合的方法实现代码修复, 生成可编译版本。

基于此, C程序构造时的在线监控流程如图 1所示, 分为以下4步。

thumbnail 图1

C程序构造时故障检测流程

1) 基于混合监控方法触发检测流程, 对构造中C程序代码片段构建副本并进行修复, 得到可编译通过的C程序。

2) 对可编译通过的C程序进行词法语法分析生成其抽象语法树。

3) 遍历抽象语法树结构, 与预识别C程序故障语法结构的规则库进行匹配。

4) 若存在与之对应的抽象语法树结构, 则调用对应的故障检测方法; 若不存在, 则结束流程, 等待下一次触发。

3 C程序构造时可编译版本生成算法

由于构造中的C程序是不完整的, 不能直接生成用于后续故障匹配以及检测的抽象语法树, 因此首先需要修复编译错误, 目前已有deepfix[15]、SYNFIX[16]等技术。其中deepfix可通过多层序列到序列的神经网络实现全局分析, 并对多个编译告警进行自动修复。deepfix通过对当前版本C程序的编译错误给出修复建议, 并检查该建议是否导致输入程序出现更多错误, 若建议合理则更新程序, 并进行下一个编译错误的修复。停止修复的情况有: ①神经网络认为输入程序正确; ②更新后的程序没有任何需要修复的编译错误; ③超过迭代修复次数的预定义上限。

本文采用deepfix代码修复技术, 并结合混合式监控机制, 设计C程序构造时代码片段的可编译版本生成算法。由于deepfix修复的程序在达到迭代修复次数的预定义上限时可能依然存在编译错误, 因此本文对该部分进行了修订, 当达到迭代次数上限但依然存在编译错误时, 则显示初始版本的编译告警, 给予开发人员提示, 并等待下一次事件触发, 然后再重新执行可编译版本生成流程。

所谓混合式监控机制, 是指当增加、删除、修改代码等事件触发较为频繁时则以时间触发模式来监控, 否则以事件触发模式来监控。如算法1所示。

算法1  C程序可编译版本生成算法

input: 构造时的C程序

output: 可编译版本C程序

initialize: Tthre←threshold_value//设置时间阈值

1. Tstart←cur_time//获取当前时间

2. L1:if event_trigger then//事件触发

3.  Tevent←cur_time//获取当前时间

4.  Tdev←Tevent-Tstart//计算时间间隔

5.  if Tdev < Tthre then//间隔时间小于阈值

6.    goto L1//继续等待事件触发

7.  else

8.    ectype←copy source_code//复制已构造的代码

9.    report←compile ectype//获取代码的编译结果

10.      if error in report then//编译结果存在错误

11.       ectype←auto_repair//调用deepfix进行自动修复

12.      end if

13.        compilable_version←ectype//得到可编译版本

14.    end if

15. end if

16. return compilable_version

设置一个时间阈值作为事件触发是否频繁的界定, 当事件触发时, 计算上一次记录的事件触发时间与当前事件的时间差, 若时间差小于时间阈值, 则采用时间触发方法, 等待下一次事件的触发, 直到时间差不小于时间阈值; 否则时间差不小于时间阈值, 触发不频繁, 采用事件触发方法, 进入后续的C程序代码片段可编译版本生成阶段。首先复制当前版本的C程序代码片段, 构建一个程序副本, 然后对该副本进行编译。当代码的不完整性或其他语法等问题导致程序不能编译通过时, 则调用deepfix对编译告警的问题进行修复, 形成可编译版本的C程序。

算法1的时间复杂度取决于代码复制和deepfix修复的时间复杂度。若n为输入代码长度, 则代码复制的复杂度为O(n); deepfix使用了多层Seq2Seq神经网络, 并带有注意力机制, 若最大迭代次数为k, 则其时间复杂度为O(k·n·m·d), 其中m为输出代码的长度, d为隐藏层的维度。因此算法1总时间复杂度为O(n+k·n·m·d), 即O(k·n·m·d)。算法1的空间复杂度取决于输入代码和输出代码所需的辅助空间, 即O(n+m)。

4 故障语法结构规则库与匹配算法

为了全面有效地检测各类故障, 针对任务安全关键软件涉及的违反断言、数组越界、空指针引用、线程死锁和饥饿5类运行时故障分析了代码具体表现形式, 归纳了43种故障类型。基于抽象语法树建立了在线编辑的C程序片段故障的规则库, 提出了一种基于规则库的语法结构匹配算法, 实现了在线编辑的C程序片段故障监控。

本节分别介绍5类运行时故障的产生条件、故障类型、抽象语法树映射规则, 以及相应的匹配算法。由于篇幅限制, 每一类故障类型, 仅列举一个故障语法结构映射规则, 以及相应的匹配算法。

4.1 违反断言

1) 故障类型

违反断言只与"assert(expression)"语句有关, 因此只有一种产生条件和故障类型, 如表 1所示。

2) 映射规则Rule1

Rule1到抽象语法树结构的映射规则以及对于C程序的assert(expression)故障表现形式, 其生成对应的抽象语法树结构如图 2所示。

thumbnail 图2

Rule1的抽象语法树

其中, 根节点的左子节点调用的是assert函数, 右子节点表示后续的expression表达式。

3) Rule1语法结构匹配算法如算法2所示, 若根节点类型为TN_FUNC_CALL, 则递归遍历该节点, 使当前节点为该节点的左子节点。若当前节点类型为TN_IDENT, 包含的字符串为“assert”, 且子节点的类型为TN_EXPR, 则根据Rule1, 将违反断言放入匹配结果中。

算法2  Rule1语法结构匹配算法

input: 抽象语法树节点node

output: 故障匹配结果error_type

1.  if (node is TN_FUNC_CALL) then

2.    recur_traverse (node)//递归遍历节点

3.    if (node is TN_IDENT) then

4.      if (node.value is "assert") then

5.        recur_traverse (node)

6.        if (node is TN_EXPR) then

7.          error_type←assert_violation

8.        end if

9.    end if

10. end if

11. return error_type

表1

违反断言故障类型划分信息表

4.2 数组越界

1) 故障类型

数组越界有下标越界、API调用越界、指针访问越界3种, 其中API调用越界主要与字符数组有关。以strcpy为例, 当目标字符与源字符长度不一或源字符是一个不以‘\0’结束的char型数组时, 目标数组可能会出现越界写入, 如表 2所示。

2) 映射规则Rule6

针对上述数组越界相关的故障类型建立到抽象语法树的映射规则: Rule2~13。本节以数组长度不一致定义(一维数组)的类型为例, 建立映射规则Rule6:数组定义(一维数组)到抽象语法树结构的映射规则, 其生成对应的抽象语法树结构如图 3所示。其中, 根节点表示定义语句, 左子节点和左子节点的子节点表示定义的类型, 右子节点表示数组声明, TN_IDENT的字符串值为数组名, 右子节点的右子节点表示定义的数组长度。

thumbnail 图3

Rule6的抽象语法树

3) Rule6语法结构匹配算法

如算法3所示, 如果节点类型为TN_DECL, 则递归遍历该节点; 若左子树根节点类型为TN_TYPE_LIST且其子节点类型为TN_TYPE, 则继续递归遍历根节点的右子树; 若右子树根节点类型为TN_ARRAY_DECL, 且其左子节点类型为TN_IDENT, 右子节点类型为TN_INT, 则符合Rule6的匹配规则, 将数组越界放入匹配结果中。

算法3  Rule6语法结构匹配算法

input: 抽象语法树节点node

output: 故障匹配结果error_type

1.  if(node is TN_DECL) then

2.    recur_traverse(node)//递归遍历节点

3.    if(node is TN_TYPE_LIST) then

4.      recur_traverse(node)//递归遍历节点

5.      if(node is TN_TYPE) then

6.        recur_traverse(node)

7.        if(node is TN_ARRAY_DECL) then

8.          recur_traverse(node)

9.          if (node is TN_IDENT) then

10.            error_type←array_bound

11.          end if

12.        end if

13.      end if

14.    end if

15. end if

16. return error_type

表2

数组越界故障类型划分信息表

4.3 空指针引用

1) 故障表现形式

空指针引用的产生条件是指针变量赋空, 其中函数赋值指针是由于当字符串操作失败或内存未分配成功等特殊情况时函数会返回NULL值, 此时可能会形成空指针, 造成空指针引用, 如表 3所示。

2) 映射规则Rule16

针对上述空指针引用相关的故障表现形式建立到抽象语法树的映射规则: Rule14~Rule25。本节以一级指针调用时赋空的表现形式为例, 建立映射规则Rule16:一级指针调用时赋空到抽象语法树结构的映射规则, 其生成对应的抽象语法树结构如图 4所示。

thumbnail 图4

Rule16的抽象语法树

其中, 根节点表示赋值操作, 第一个子节点中TN_IDENT的字符串值为指针变量名, 第二个子节点和第三个子节点表示赋空。

3) Rule16语法结构匹配算法

如算法4所示。

算法4  Rule16语法结构匹配算法

input: 抽象语法树节点node

output: 故障匹配结果error_type

1.  if (node is TN_ASSIGN) then

2.    recur_traverse(node)//递归遍历节点

3.    if (node is TN_IDENT) then

4.      recur_traverse(node)//递归遍历节点

5.        if (node is SYMBOL and node.value is "=") then

6.        recur_traverse(node)

7.        if (node is TN_IDENT and node.value is "NULL") then

8.          error_type←null_pointer_dereference

9.        end if

10.      end if

11.    end if

12. end if

13. return error_type

如果根节点类型为TN_ASSIGN, 则递归遍历该节点, 若第一个子节点类型为TN_IDENT, 第二个子节点类型为SYMBOL且值为“=”, 第三个子节点类型为TN_IDENT其值为NULL, 则符合Rule16的匹配规则, 将空指针引用放入匹配结果中。

表3

空指针引用故障类型划分信息表

4.4 死锁与饥饿

1) 故障表现形式

由于死锁和饥饿都存在于并发多线程中, 因此两者的产生条件都与POSIX标准头文件以及Solaris标准头文件有关, 此处只罗列了其较为常见的表现形式, 如表 4所示。

2) 映射规则Rule30

针对上述死锁与饥饿相关的故障表现形式建立到抽象语法树的映射规则: Rule26~Rule43。本节以pthread_cond_t为例, 建立映射规则Rule30:条件变量定义pthread_cond_t到抽象语法树结构的映射规则, 其生成对应的抽象语法树结构如图 5所示。

thumbnail 图5

Rule30的抽象语法树

其中, 根节点表示定义语句, 左子节点及其子节点表示定义的类型为pthread_mutex_t, 右子节点TN_IDENT的字符串值为互斥量名。

3) Rule30语法结构匹配算法

如算法5所示, 如果根节点类型为TN_DECL_CALL, 则递归遍历该节点, 使当前节点为该节点的左子节点。若当前节点类型为TN_TYPE, 且包含的字符串为"pthread_cond_t", 则继续遍历根节点的右子树; 若右子树根节点类型为TN_IDENT, 则符合Rule30的匹配规则, 将死锁和饥饿放入匹配结果中。

算法5  Rule30语法结构匹配算法

input: 抽象语法树节点node

output: 故障匹配结果error_type

1.  if (node is TN_DECL) then

2.    recur_traverse(node)

3.    if (node is TN_TYPE_LIST) then

4.      recur_traverse(node)

5.        if(node is TN_TYPE and node.value is "pthread_cond_t") then

6.        recur_traverse(node)

7.        if(node is TN_IDENT) then

8.        error_type←deadlock or starvation

9.        end if

10.      end if

11.    end if

12. end if

13. return error_type

表4

死锁、饥饿故障类型划分信息表

4.5 算法性能分析

根据算法2~5可知, 故障匹配过程包括源代码建立抽象语法树和抽象语法树的遍历2个阶段, 其中抽象语法树的建立分为语法分析和词法分析, 其时间复杂度和空间复杂度均为O(n), n为源代码的长度。抽象语法树的遍历采用DFS算法, 其时间复杂度为O(t), t为树中节点的数量; 空间复杂度为O(h), h为树的高度。因此故障匹配算法总的时间复杂度为O(n+t), 空间复杂度为O(n+h)。可见, 算法随问题规模, 即源代码长度的增长, 时间开销和空间开销呈线性增长, 能够满足处理大规模代码时的性能需求。

5 实验验证

5.1 实验对象

本文选取了表 5所示的50个程序作为实验对象, 这些程序源码来自“软件定义卫星站控系统”和“基于国产操作系统的飞控核心软件形式化验证”等项目的工程代码, 涵盖了航空、航天等安全关键领域常用的线性表、树、图等数据结构的查找、遍历、排序等操作, 以及多线程处理、网络通信、总线通信等不同功能; 程序规模从几十行到数千行不等; 程序复杂度包括O(log2n), O(n), O(nlog2n), O(n2), O(n3)等。所选案例的程序源码覆盖了本文介绍的43种故障表现形式, 具有较好的代表性。本文将依据上述方法, 在构建这些程序案例时, 检查是否按规则库匹配到相应的故障类型。

表5

实验结果表(节选)

5.2 实验过程

本节以表 5中的Driver_receiv1553.c程序为例, 介绍具体的检测流程和实验过程。该程序主要负责从1553b总线接收数据, 从接收到的数据读取相关信息, 如命令字、数据长度、数据块等, 对接收数据块的有效性进行判断, 该程序定义了10个数组对象, 其中包括2个指针数组。

首先对于Driver_receiv1553.c程序随机选取了前123行作为当前正在构造的代码片段, 基于混合式监控方法生成可编译版本, 设置时间阈值为5 s。当事件时间差超过阈值时, 对当前程序的副本进行编译。由于程序不完整, 存在编译错误, 因此调用deepfix进行修复。本实验中deepfix迭代修复2次, 如图 6~8所示(修复内容为标记处)。当第二次修复后, 满足停止修复的条件(更新后的程序没有任何需要修复的编译错误), 形成可编译通过的C程序。

thumbnail 图6

构造时的C程序

thumbnail 图7

第一次迭代修复后的C程序

thumbnail 图8

可编译通过的C程序(第二次迭代修复)

接着, 生成可编译版本代码的抽象语法树, 由于完整的抽象语法树比较繁杂, 本文只展示部分数据对象的抽象语法树。图 9展示了指针数组ADS_var_safe与ADS_var_o的抽象语法树。抽象语法树的示意图中, 节点均标明了类型, 叶子节点中展示了具体的字符串值信息。

thumbnail 图9

指针数组ADS_var_safe与ADS_var_o的抽象语法树示意图

最后, 按照本文提出的C程序运行时故障语法结构的规则库及C程序构造时监控算法, 生成匹配结果。在图 9中, 当遍历到TN_ASSIGN节点时, 与规则库中的Rule19进行匹配, 最终匹配成功, 识别到运行时故障——“指针数组赋空”。

5.3 实验结果及分析

实验结果共计匹配到41种故障类型, 146个潜在运行时故障均正确反馈。实验数据信息如表 5所示, 其中停止修复的原因如第3节所述共有3种, 编号分别为①, ②, ③。

在案例13和39中, 初始构建的程序未能在达到迭代修复次数的上限前形成可编译版本, 因此继续构建代码, 当事件时间差超过阈值时, 重新执行可编译版本生成流程, 此次在迭代修复2次后得到可编译版本。此外, 经过C程序抽象语法树与规则库的对照分析, 案例34和40由于已构建的程序未出现相应结构, 因此结果分别缺少F20、F21故障类型。整体来说, 实验结果均符合预期, 表明本文所提出的监控方法能够有效识别潜在故障, 提高软件安全性和可信性。

6 结论

任务安全关键领域软件使用C语言开发的程序存在潜在的安全风险, 易导致运行时故障, 造成巨大损失, 本文针对此类问题, 总结、分析了现有软件监控方法的特点和不足, 提出了一种任务安全关键软件C程序构造时的在线监控方法, 在构造C程序时对代码进行监控和静态分析, 高效监测潜在故障。首先, 针对在线编辑的C程序片段的实时编译及测试问题, 提出了一种混合式监控方法的片段程序可编译版本自动生成技术, 可有效减少监控开销, 并通过现有的代码修复技术处理当前不完整的C程序, 生成可编译通过的版本。其次, 针对任务安全关键软件常见的指针操作不严格限定、数组和字符串缺乏边界检查等5类运行时故障的产生条件归纳出43种故障类型, 基于抽象语法树建立在线编辑的C程序片段故障的规则库。在此基础上, 提出基于语法结构匹配算法识别潜在运行时故障, 实现了在线编辑的C程序片段故障的构造时在线监控功能。最后, 对50个C程序进行了实验验证, 共匹配41种故障类型, 发现146个潜在故障, 表明本文所提出的监控方法能够有效识别潜在故障, 提高软件安全性和可信性, 且执行效率高, 开销较低, 具有很好的实用性。后续将针对C++和Java等其他主流编程语言, 优化可编译版本生成方法, 并研究其故障类型, 形成适用于不同语言的规则库。

References

  1. ZHOU J, ZHANG M X. Survey on trustworthy software evaluation[J]. Application Research of Computers, 2012, 29(10): 3609–3613 [Google Scholar]
  2. LIU Ke, SHAN Zhiguang, WANG Ji, et al. Overview on major research plan of trustworthy software[J]. Bulletin of National Natural Science Foundation of China, 2008(3): 145–151 (in Chinese) [Google Scholar]
  3. LANG Bo, LIU Xudong, WANG Huaimin, et al. A classification model for software trustworthiness[J]. Journal of Frontiers of Computer Science and Technology, 2010, 4(3): 231–239 (in Chinese) [Google Scholar]
  4. LI S, LIU S. A software tool to support scenario-based formal specification for error prevention[J]. Lecture Notes in Computer Science, 2018, 10795: 187–199 [Google Scholar]
  5. WANG P, LIU S, LIU A Z F. A framework for modeling and detecting security vulnerabilities in human-machine pair programming[J]. Journal of Internet Technology, 2022, 23(5): 1129–1138 [Google Scholar]
  6. SCHUBERT P D, NIXDORF H, HERMANN B, et al. Lossless, persisted summarization of static callgraph, points-to and data-flow analysis[C]//Leibniz International Proceedings in Informatics, 2021 [Google Scholar]
  7. WANG P, LIU S, JIANG L W. Detecting security vulnerabilities with vulnerability nets[J]. The Journal of Systems and Software, 2024, 208: 111902 [Google Scholar]
  8. DAI Yujun, LIU Shaoying, XU Guangquan. Enhancing human-machine pair inspection with risk number and code inspection diagram[J]. Software Quality Journal, 2024, 32(3): 939–959 [Google Scholar]
  9. PAN Sen, LIN Yun, PENG Xin, et al. Visualised product quality monitoring tool based on software development process data[J]. Computer Applications and Software, 2015, 32(9): 8–12 (in Chinese) [Google Scholar]
  10. RONCHIERI E, CANAPARO M. A software quality predictive model[C]//International Conference on Software Engineering and Applications, 2013 [Google Scholar]
  11. BIELIKOVÁ M, POLÁŠEK I, BARLA M, et al. Platform independent software development monitoring: design of an architecture[J]. Lecture Notes in Computer Science, 2014, 8327: 126–137 [Google Scholar]
  12. ALLAMANIS M, BROCKSCHMIDT M, KHADEMI M. Learning to represent programs with graphs[C]//6th International Conference on Learning Representations, 2018 [Google Scholar]
  13. LAL H, PAHWA G. Code review analysis of software system using machine learning techniques[C]//2017 11th International Conference on Intelligent Systems and Control, 2017 [Google Scholar]
  14. SZABÓ Z, BILICKI V. A new approach to web application security: utilizing GPT language models for source code inspection[J]. Future Internet, 2023, 15(10): 326 [Google Scholar]
  15. GUPTA R, PAL S, KANADE A, et al. Deepfix: fixing common C language errors by deep learning[C]//National Conference on Artificial Intelligence, 2017 [Google Scholar]
  16. AHMED T, LEDESMA N R, DEVANBU P. Synshine: improved fixing of syntax errors[J]. IEEE Trans on Software Engineering, 2021, 49: 2169–2181 [Google Scholar]

All Tables

表1

违反断言故障类型划分信息表

In the text
表2

数组越界故障类型划分信息表

In the text
表3

空指针引用故障类型划分信息表

In the text
表4

死锁、饥饿故障类型划分信息表

In the text
表5

实验结果表(节选)

In the text

All Figures

thumbnail 图1

C程序构造时故障检测流程
In the text
thumbnail 图2

Rule1的抽象语法树
In the text
thumbnail 图3

Rule6的抽象语法树
In the text
thumbnail 图4

Rule16的抽象语法树
In the text
thumbnail 图5

Rule30的抽象语法树
In the text
thumbnail 图6

构造时的C程序
In the text
thumbnail 图7

第一次迭代修复后的C程序
In the text
thumbnail 图8

可编译通过的C程序(第二次迭代修复)
In the text
thumbnail 图9

指针数组ADS_var_safe与ADS_var_o的抽象语法树示意图
In the text

Current usage metrics show cumulative count of Article Views (full-text article views including HTML views, PDF and ePub downloads, according to the available data) and Abstracts Views on Vision4Press platform.

Data correspond to usage on the plateform after 2015. The current usage metrics is available 48-96 hours after online publication and is updated daily on week days.

Initial download of the metrics may take a while.