代码之家 › 专栏 › 技术社区 › BCS

程序的有效状态域是正规语言吗?

formal-languages stack-trace bug-tracking

0

BCS · 技术社区 · 15 年前

如果查看程序的调用堆栈并将每个返回指针视为标记, 为程序的有效状态建立识别器需要什么样的自动机?

作为推论, 需要什么样的自动机来为特定的错误状态构建识别器?

(注:我只是在看可能来自 this function )

我的想法是,如果这些形式的正规语言比一些有趣的工具可以建立在这一点上。例如,给定一组崩溃/故障转储,自动将它们分组并生成识别器,以识别已知错误的新实例。

注意:我不是建议将其作为一个诊断工具,而是作为一个数据管理工具,用于将一堆崩溃报告转换为更有用的东西。

似乎我还不清楚自己的目标是什么,下面是一个例子:

假设你有一个程序有三个错误。

同样,当程序崩溃时(失败的断言、未捕获的异常、seg-v、堆栈溢出等),它会捕获堆栈跟踪,提取其中的调用站点并将它们发送到qa报告服务器。(我假设只提取这些信息,因为1,每个项目成本一次很容易得到,2,它有一个简单、明确的含义,可以在不需要对程序有任何特殊知识的情况下使用)

我建议使用一个工具,尝试将传入的报告分类为与已知错误(或新错误)相关的报告。

最简单的事情是假设一个故障站点是一个bug,但是在第一个示例中,在同一个位置检测到两个bug。下一个最简单的事情是要求整个堆栈匹配,但同样,这在第二个示例中不起作用,在第二个示例中,您有多个(有效的)有效代码片段可以触发同一个bug。

2 回复 | 直到 15 年前

1

0

jmucchiello 15 年前

堆栈上的返回指针只是指向内存的指针。理论上,如果你看一个只调用一个函数的程序的调用堆栈,返回指针(对于那个函数)对于程序的每次执行都有不同的值。你会怎么分析?

理论上,您可以使用映射文件读取核心转储。但是这样做是非常特定于平台和编译器的。使用任何程序都无法创建用于执行此操作的通用工具。请阅读编译器的文档,看看它是否包含任何用于进行死后分析的工具。

2

0

S.Lott 15 年前

如果程序用assert语句修饰,则每个assert语句都定义一个有效状态。断言之间的程序语句定义有效的状态更改。

一个崩溃的程序已经违反了足够多的断言。

一个不正确但“不稳定”的程序至少违反了一个断言,但没有失败。

根本不清楚你在找什么。有效状态有时很难定义,但通常很容易表示为 assert 声明。

由于崩溃的程序违反了一个或多个断言,因此具有显式可执行断言的程序不需要崩溃调试。它只会使assert语句失败,并明显死亡。

如果不想放入assert语句,那么基本上不可能知道什么状态应该是真的,并且(从未实际声明)的断言被违反。

展开调用堆栈以计算位置和嵌套很简单。但还不清楚这说明了什么。它告诉你什么东西坏了,但不是其他什么东西导致的。这需要猜测哪些断言应该是正确的,这需要对设计有深入的了解。

编辑。

“似乎相关”和“似乎无关”是不可解释的,不依赖于实际应用程序的实际设计和应该在每个堆栈帧中为真。

如果你不知道应该说真的,你只有一堆随机变量。给定一堆随机值,您可以对“相关”声明什么?

Crash 1: a = 2, b = 3, c = 4 

Crash 2: a = 3, b = 4, c = 5

相关的?无关的?你怎么能不知道就把这些分类一切关于密码?如果你知道一切关于代码,您可以制定标准 断言 -陈述条件 应该是 真的。然后你就知道真正的坠机是什么了。