当一个控件的类名非常长时，为什么会出现访问冲突？

Question

当一个控件的类名非常长时，为什么会出现访问冲突？

delphidelphi-2010buffer-overflow

23

我创建了一个控件的子类，以添加一些所需的字段，但是现在当我在运行时创建它时，会出现“访问冲突”的错误。不幸的是，这个访问冲突并不发生在我创建控件的地方，即使我使用了所有调试选项（包括“使用调试 DCU 进行构建”），堆栈跟踪也无法帮助我！

为了重现这个错误，我尝试创建一个控制台应用程序，但显然，这个错误只会在窗体应用程序中出现，并且只有在我的控件实际上显示在窗体上时才会出现！

以下是重现错误的步骤。创建一个新的 VCL 窗体应用程序，放置一个按钮，双击以创建 OnClick 处理程序并编写以下内容：

type TWinControl<T,K,W> = class(TWinControl);

procedure TForm3.Button1Click(Sender: TObject);
begin
  with TWinControl<TWinControl, TWinControl, TWinControl>.Create(Self) do
  begin
    Parent := Self;
  end;
end;

这会连续生成访问冲突，每次我都尝试。只在Delphi 2010上进行了测试，因为这是我电脑上唯一的版本。

问题如下：

这是Delphi泛型中已知的bug吗？
有没有解决方法？

编辑

以下是QC报告链接：http://qc.embarcadero.com/wc/qcmain.aspx?d=112101

- Cosmin Prund

7

下次在发布问题时，如果您已经知道了答案，请点击“回答自己的问题”框，这样您就可以同时发布问题和答案。 - Rob Kennedy

6

我指的是“提问”页面上的复选框。您可以同时提问和回答。 - Rob Kennedy

1

@NGLN，随意编辑并使标题更有用。我不知道怎么可能再次遇到这个问题，但我确实花了很长时间才弄清楚，所以我希望它能帮助某人。 - Cosmin Prund

1

我正在忙于调试并准备发布答案时，你的回答出现了。我没有意识到我们正在玩游戏。那好吧，你可能可以拦截 TWinControl.CreateParams 并从内部修复它。你已经提交了 QC 报告吗？ - David Heffernan

3

@DavidHeffernan: http://qc.embarcadero.com/wc/qcmain.aspx?d=112101 - Cosmin Prund

显示剩余11条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Cosmin Prund · Accepted Answer

首先，这与泛型无关，但在使用泛型时更容易出现。原来在TControl.CreateParams中存在缓冲区溢出漏洞。如果您查看代码，您会注意到它填充了一个TCreateParams结构体，特别重要的是，它用当前类（ClassName）的名称填充了TCreateParams.WinClassName。不幸的是，WinClassName是一个仅包含64个字符的固定长度缓冲区，但需要包括空终止符; 因此，一个长度为64的ClassName将使该缓冲区溢出！

可以使用以下代码进行测试：

TLongWinControlClassName4567890123456789012345678901234567891234 = class(TWinControl)
end;

procedure TForm3.Button1Click(Sender: TObject);
begin
  with TLongWinControlClassName4567890123456789012345678901234567891234.Create(Self) do
  begin
    Parent := Self;
  end;
end;

这个类名恰好有64个字符长度。将它缩短一个字符，错误将消失！

当使用泛型时，这种情况发生的可能性更大，因为Delphi构造ClassName的方式：它包括参数类型所在的单元名称，加上一个点，然后是参数类型的名称。例如，TWinControl<TWinControl, TWinControl, TWinControl>类的ClassName如下：

TWinControl<Controls.TWinControl,Controls.TWinControl,Controls.TWinControl>

这句话有75个字符，超过了63的限制。

解决方案

我采用了一个简单的错误信息，从可能生成错误的类中获取。例如从构造函数中获取如下内容：

constructor TWinControl<T, K, W>.Create(aOwner: TComponent);
begin
  {$IFOPT D+}
  if Length(ClassName) > 63 then raise Exception.Create('The resulting ClassName is too    long: ' + ClassName);
  {$ENDIF}
  inherited;
end;

至少这个错误信息可以让人立即采取行动。

后续编辑，真正的解决方案

之前的解决方法（抛出一个错误）对于非泛型类并且类名非常长的情况可以运作良好；很可能可以缩短类名，使其小于63个字符。但是对于泛型类型就不是这样了：我在一个具有两个类型参数的TWinControl子类中遇到了这个问题，因此它的形式如下：

TMyControlName<Type1, Type2>

根据这个泛型类型生成具体类型的类名采用如下形式：

TMyControlName<UnitName1.Type1,UnitName2.Type2>

因此，它包括5个标识符（2个单位标识符+3个类型标识符）+5个符号（<.,.>）。这5个标识符的平均长度需要小于12个字符，否则总长度超过63：5x12 + 5 = 65。每个标识符仅使用11-12个字符非常少，违反了最佳实践（即：使用长描述性名称，因为按键是免费的！）。在我的情况下，我根本无法将标识符缩短到那么短。

考虑到缩短ClassName并不总是可能的，我想试图消除问题的原因（缓冲区溢出）。不幸的是，这很困难，因为错误源自TWinControl.CreateParams，位于CreateParams层次结构的底部。我们不能不调用inherited，因为CreateParams沿着继承链一直被用来构建窗口创建参数。如果不调用它，就需要复制基本TWinControl.CreateParams中的所有代码以及中间类中的所有代码；这也不太可移植，因为任何该代码都可能随着VCL的未来版本（或我们可能正在子类化的第三方控件的未来版本）而改变。

以下解决方案无法阻止TWinControl.CreateParams溢出缓冲区，但使其无害，然后（当inherited调用返回时）解决问题。我使用一个新记录（因此我可以控制布局），其中包括原始的TCreateParams，但将其填充了大量空间以便TWinControl.CreateParams溢出。 TWinControl.CreateParams想要溢出多少就让它溢出，然后我读取完整的文本并使其适合记录的原始边界，还确保生成的缩短名称具有相当高的唯一性。我在WndName中包括原始ClassName的哈希值以帮助解决唯一性问题：

type
  TWrappedCreateParamsRecord = record
    Orignial: TCreateParams;
    SpaceForCreateParamsToSafelyOverflow: array[0..2047] of Char;
  end;

procedure TExtraExtraLongWinControlDescendantClassName_0123456789_0123456789_0123456789_0123456789.CreateParams(var Params: TCreateParams);
var Wrapp: TWrappedCreateParamsRecord;
    Hashcode: Integer;
    HashStr: string;
begin
  // Do I need to take special care?
  if Length(ClassName) >= Length(Params.WinClassName) then
    begin
      // Letting the code go through will cause an Access Violation because of the
      // Buffer Overflow in TWinControl.CreateParams; Yet we do need to let the
      // inherited call go through, or else parent classes don't get the chance
      // to manipulate the Params structure. Since we can't fix the root cause (we
      // can't stop TWinControl.CreateParams from overflowing), let's make sure the
      // overflow will be harmless.
      ZeroMemory(@Wrapp, SizeOf(Wrapp));
      Move(Params, Wrapp.Orignial, SizeOf(TCreateParams));
      // Call the original CreateParams; It'll still overflow, but it'll probably be hurmless since we just
      // padded the orginal data structure with a substantial ammount of space.
      inherited CreateParams(Wrapp.Orignial);
      // The data needs to move back into the "Params" structure, but before we can do that
      // we should FIX the overflown buffer. We can't simply trunc it to 64, and we don't want
      // the overhead of keeping track of all the variants of this class we might encounter.
      // Note: Think of GENERIC classes, where you write this code once, but there might
      // be many-many different ClassNames at runtime!
      //
      // My idea is to FIX this by keeping as much of the original name as possible, but
      // including the HASH value of the full name into the window name; If the HASH function
      // is any good then the resulting name as a very high probability of being Unique. We'll
      // use the default Hash function used for Delphi's generics.
      HashCode := TEqualityComparer<string>.Default.GetHashCode(PChar(@Wrapp.Orignial.WinClassName));
      HashStr := IntToHex(HashCode, 8);
      Move(HashStr[1], Wrapp.Orignial.WinClassName[High(Wrapp.Orignial.WinClassName)-8], 8*SizeOf(Char));
      Wrapp.Orignial.WinClassName[High(Wrapp.Orignial.WinClassName)] := #0;
      // Move the TCreateParams record back were we've got it from
      Move(Wrapp.Orignial, Params, SizeOf(TCreateParams));
    end
  else
    inherited;
end;