如何调试（可能的）RTL 问题？

Question

我问这个问题是因为我没有好主意……希望得到别人的新观点。

我有一个用户在 Windows 7 64 位系统上运行我们的 32 位 Delphi 应用程序（用 BDS 2006 编译）。直到几周前，我们的软件都“运行良好”。现在突然就不是了：它在初始化（实例化对象）时抛出访问冲突。

我们让他重新安装了我们所有的软件——从头开始。同样的 AV 错误。我们禁用了他的防病毒软件；同样的错误。

由于某种原因，我们的堆栈跟踪代码 (madExcept) 无法提供错误行的堆栈跟踪，因此我们发送了几个错误日志记录版本供用户安装和运行，以隔离生成错误的行...

结果是，这是一个实例化简单 TStringList 后代的行（没有覆盖的 Create 构造函数等） .--基本上创建是只是实例化一个 TStringList，它有一些与后代类关联的自定义方法。）

我很想向用户发送另一个测试 .EXE；它只是实例化一个普通的 TStringList，看看会发生什么。但在这一点上，我感觉自己就像在风车上猛烈地挥舞，如果我发送太多“要尝试的东西”，就有可能耗尽用户的耐心。

关于调试该用户问题的更好方法有什么新想法吗？ （我不喜欢解决用户的问题......这些问题往往是如果被忽视，就会突然成为其他 5 个用户突然“发现”的流行病。）

编辑，正如 Lasse 所要求的：

procedure T_fmMain.AfterConstruction;
begin
  inherited;
      //Logging shows that we return from the Inherited call above,
      //then AV in the following line...
  FActionList := TAActionList.Create;
  ...other code here...
end;

这是定义正在创建的对象...

type
  TAActionList = class(TStringList)
  private
    FShadowList: TStringList;              //UPPERCASE shadow list
    FIsDataLoaded : boolean;
  public
    procedure AfterConstruction; override;
    procedure BeforeDestruction; override;
    procedure DataLoaded;
    function Add(const S: string): Integer; override;
    procedure Delete(Index : integer); override;
    function IndexOf(const S : string) : Integer; override;
  end;

implementation

procedure TAActionList.AfterConstruction;
begin
  Sorted := False;              //until we're done loading
  FShadowList := TStringList.Create;
end;

Answer 1

我讨厌这类问题，但我认为您应该在对象尝试构建之前关注最近发生的事情。

您描述的症状听起来像是典型的堆损坏，所以也许您有类似的情况......

• 数组被写入外部边界？ （如果关闭了边界检查，请打开它）
• 代码试图访问已被删除的对象？

由于我上面的回答，您已经发布了代码片段。这确实提出了一些我认为可能存在的问题。

a：AfterConstruction 与修改后的构造函数：
正如其他人所提到的，以这种方式使用 AfterConstruction 充其量不是惯用的。我不认为这真的是“错误”，但它可能是一种气味。 Dr. 对这些方法有很好的介绍。 Bob 的站点在这里。

b：重写方法 Add、Delete、IndexOf
我猜测这些方法以某种方式使用 FshadowList 项。在创建 FShadowList 之前是否有可能调用这些方法（并因此使用 FShadowList）？这似乎是可能的，因为您正在使用上面的 AfterConstruction 方法，此时虚拟方法应该“起作用”。希望通过设置一些断点并查看它们被击中的顺序，可以使用调试器轻松检查这一点。

Answer 2

您不应该永远重写程序中的AfterConstruction 和BeforeDestruction 方法。它们并不是用于您正在使用它们所做的事情，而是用于低级 VCL 黑客攻击（如引用添加、自定义内存处理等）。

您应该重写 Create 构造函数 和 Destroy destructor 并将初始化代码放在这里，如下所示：

constructor TAActionList.Create;
begin
  inherited; 
  // Sorted := False; // not necessary IMHO
  FShadowList := TStringList.Create;
end;

看一下 VCL 代码，以及所有正式发布的 Delphi 代码，以及您会发现 AfterConstruction 和 BeforeDestruction 方法从未被使用过。我想这是您问题的根本原因，因此必须修改您的代码。在 Delphi 的未来版本中情况可能会更糟。

Answer 3

显然，TAActionList 在构建时所做的事情没有任何可疑之处。即使考虑祖先构造函数和设置 Sorted := False 可能产生的副作用，也表明应该不会有问题。我对 T_fmMain 内部发生的事情更感兴趣。

基本上，发生了一些事情导致 FActionList := TAActionList.Create; 失败，即使 TAActionList.Create 的实现没有任何错误（可能是形式可能已被意外破坏）。

我建议您尝试按如下方式更改 T_fmMain.AfterConstruction：

procedure T_fmMain.AfterConstruction;
begin
  //This is safe because the object created has no form dependencies 
  //that might otherwise need to be initialised first.
  FActionList := TAActionList.Create;

  //Now, if the ancestor's AfterConstruction is causing the problem, 
  //the above line will work fine, and...
  inherited AfterConstruction;

  //... your error will have shifted to one of these lines here.
  //other code here
end;

如果您的表单使用的组件的环境问题导致它在 AfterConstruction 期间破坏表单，那么它的分配实际导致 AV 的 FActionList 的新 TAActionList.Create 实例。另一种测试方法是首先将对象创建为局部变量，然后将其分配给类字段：FActionList := LActionList。

环境问题可能很微妙。例如，我们使用一个报告组件，我们发现该组件需要安装打印机驱动程序，否则它会阻止我们的应用程序启动。

您可以通过在表单的析构函数中设置全局变量来确认破坏理论。此外，您还可以从析构函数输出堆栈跟踪，以确认导致表单破坏的确切顺序。

Answer 4

我们的软件一直“运行良好”，直到几周前......突然成为一种流行病，其他 5 个用户突然“发现”。）：

听起来你需要这样做一些取证分析，而不是调试：您需要发现该用户环境中发生了什么变化来触发错误。更重要的是，如果您有其他用户使用相同的部署但没有问题（听起来这就是您的情况）。向用户发送“要尝试的事情”是快速削弱用户信心的最佳方法之一！ （如果用户现场有 IT 支持，请让他们参与，而不是让用户参与）。

对于初学者，请探索以下选项：

*) 如果可能，我会检查 Windows 事件日志以查找问题出现时该计算机上可能发生的事件。

*) 用户方面是否有某种 IT 支持人员可以与您讨论该用户环境中可能发生的更改/问题？

*) 在错误出现时，该用户是否存在某种可能与之相关的支持问题/事件，和/或导致他们特有的某种数据或文件损坏？

（至于代码本身，我同意@Warran P关于解耦等的观点）

Answer 5

当 MadExcept 不够时要做的事情（我必须说，这种情况很少见）：

1. 尝试 Jedi JCL 的 JCLDEBUG。如果您将 MadExcept 更改为 JCLDEBUG，并直接将堆栈跟踪写入磁盘而不进行任何 UI 交互，您可能会获得堆栈跟踪。

2. 运行像 MS/SysInternals debugview 这样的调试查看器，并跟踪输出内容，例如发生问题的对象的 Self 指针。我怀疑不知何故，一个无效的实例指针最终出现在那里。

3. 解耦事物并重构事物，并编写单元测试，直到您发现真正丑陋的事物正在摧毁您。 （有人建议堆损坏。我经常发现堆损坏与不安全、丑陋的未经测试的代码以及深度绑定的 UI+模型级联故障密切相关。）