跟踪未初始化的静态变量

Question

我需要调试一个丑陋且巨大的数学 C 库，可能曾经由 f2c 生成。该代码滥用了本地静态变量，不幸的是，它似乎在某个地方利用了这些变量自动初始化为 0 的事实。如果使用相同的输入调用其入口函数两次，则会给出不同的结果。如果我卸载该库并再次重新加载，它将正常工作。它需要很快，所以我想摆脱加载/卸载。

我的问题是如何使用 valgrind 或任何其他工具发现这些错误，而无需手动遍历整个代码。

我正在寻找声明局部静态变量的地方，首先读取，然后才写入。由于静态变量有时通过指针进一步传递（是的 - 它太难看了），问题变得更加复杂。

我理解有人可能会说这样的错误不一定需要由自动工具检测到，因为在某些情况下这正是预期的行为。不过，有没有办法让自动初始化的局部静态变量变得“脏”？

Answer 1

细节决定成败，但这可能对您有用：

首先，获取 Frama-C。如果您使用的是 Unix，您的发行版可能有一个软件包。该软件包不会是最后一个版本，但它可能已经足够好，并且如果您以这种方式安装它，它将节省您一些时间。

假设您的示例如下所示，只是太大了以至于不明显出了什么问题：

int add(int x, int y)
{
  static int state;
  int result = x + y + state; // I tested it once and it worked.
  state++;
  return result;
}

键入如下命令：

frama-c -lib-entry -main add -deps ugly.c

Options -lib-entry -main add 意思是“查看函数add”。选项-deps计算函数依赖关系。您将在日志中找到这些“功能依赖项”：

[from] Function add:
     state FROM state; (and default:false)
     \result FROM x; y; state; (and default:false)

这列出了 add 结果所依赖的实际输入，以及实际输出根据这些输入计算，包括读取和修改的静态变量。在使用之前正确初始化的静态变量通常不会作为输入出现，除非分析器无法确定它在读取之前始终已初始化。

日志将 state 显示为 \result 的依赖项。如果您期望返回的结果仅取决于参数（意味着具有相同参数的两次调用会产生相同的结果），则暗示变量 state 可能存在问题。

上面几行显示的另一个提示是该函数修改state。

这可能有帮助，也可能没有帮助。选项 -lib-entry 意味着分析器不会假设任何非常量静态变量在调用分析的函数时保持其值，因此这对于您的代码来说可能太不精确。有很多方法可以解决这个问题，但这取决于你是否愿意花时间去学习这些方法。

编辑：这是一个更复杂的示例：

void initialize_1(int *p)
{
  *p = 0;
}

void initialize_2(int *p)
{
  *p; // I made a mistake here.
}

int add(int x, int y)
{
  static int state1;
  static int state2;

  initialize_1(&state1);
  initialize_2(&state2);

  // This is safe because I have initialized state1 and state2:
  int result = x + y + state1 + state2; 

  state1++;
  state2++;
  return result;
}

在此示例中，相同的命令生成结果：

[from] Function initialize_1:
         state1 FROM p
[from] Function initialize_2:
[from] Function add:
         state1 FROM \nothing
         state2 FROM state2
         \result FROM x; y; state2

您看到的 initialize_2 是一个空的依赖项列表，这意味着该函数不分配任何内容。我将通过显示明确的消息而不仅仅是空列表来使这种情况更清楚。如果您知道 initialize_1、initialize_2 或 add 函数的用途，您可以将此先验知识与以下结果进行比较分析后发现 initialize_2 和 add 有问题。

第二次编辑：现在我的示例显示了 initialize_1 的一些奇怪之处，所以也许我应该解释一下。变量 state1 取决于 p，因为 p 用于写入 state1，并且如果 p 不同，那么 state1 的最终值也会不同。这是最后一个示例：

int t[10];

void initialize_index(int i)
{
  t[i] = 1;
}

int main(int argc, char **argv)
{
  initialize_index(argv[1][0]-'0');
}

使用命令 frama-c -deps tc，为 initialize_index 计算的依赖关系为：

[from] Function initialize_index:
         t[0..9] FROM i (and SELF)

这意味着每个单元都依赖于 i （如果i 是该特定单元格的索引，则可以对其进行修改）。每个单元格还可以保留其值（如果i表示另一个单元格）：这在最新版本中用（和SELF）提及来指示，并用更多指示在以前的版本中晦涩难懂的（默认值：true）。

Answer 2

静态代码分析工具非常擅长发现典型的编程错误，例如使用未初始化的变量。 这里是针对 C 语言执行此操作的免费工具列表。

不幸的是，我无法推荐列表中的任何工具。我只熟悉两种商业产品，Coverity 和 Klocwork。覆盖率非常好（而且昂贵）。 Klocwork就一般般了（但更便宜）。

Answer 3

我最终所做的是通过“#define static”从代码中删除所有静态限定符。这会将未初始化的静态使用转变为无效使用，并且这些工具可以发现我正在寻找的滥用类型。

在我的实际情况中，这足以确定错误的位置，但在更一般的情况下，如果静态实际上正在做一些重要的事情，则应该通过在代码无法继续时逐渐重新添加“静态”来进行改进。

Answer 4

我不知道有哪个库可以为您执行此操作，但我会考虑使用正则表达式来查找它们。 这样的东西

像rgrep "static\s*int" path/to/src/root | grep -v = | grep -v "("

这应该返回所有没有等号声明的静态 int 变量，最后一个管道应该删除其中带有括号的任何内容（摆脱函数）。有一个很好的改变，这并不完全适合你，但是使用 grep 可能是您追踪此问题的最快方法，

当然，一旦找到有效的方法，您也可以将 int 替换为所有其他类型的变量来搜索这些变量。

Answer 5

我的问题是如何发现这些错误......

但是这些不是错误：静态变量初始化为 0 的期望是完全有效的，就像为它分配一些其他值一样。

因此，要求一个能够自动发现非错误的工具不太可能产生令人满意的结果。

从您的描述来看， somefunc() 在第一次调用时返回正确的结果，在后续调用中返回错误的结果。

调试此类问题的最简单方法是并排使用两个 GDB 会话：一个是新加载的（将计算正确的答案），另一个是“第二次迭代”（将计算错误的答案）。然后“并行”地逐步执行两个会话，并查看它们的计算或控制流在哪里开始出现分歧。

由于您通常可以有效地将问题一分为二，因此通常不需要很长时间就能找到错误。 总是重现的错误是最容易发现的。去做就对了。