我按顺序继承了一个控件,所以我可以添加一些我需要的字段,但现在当我在运行时创建它时,我得到一个Access Violation
。不幸的是,这种访问冲突不会发生在我正在创建控件的地方,甚至那些我在启用所有调试选项的情况下构建的(包括“使用调试DCU构建”)堆栈跟踪根本无法帮助我!
在尝试重现错误时,我尝试创建一个控制台应用程序,但显然这个错误只出现在Forms应用程序中,并且只有当我的控件实际显示在表单上时才会显示!
以下是重现错误的步骤。创建一个新的VCL Forms应用程序,单击一个按钮,双击以创建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上测试过,因为这是我在这台计算机上唯一的版本。
问题是:
以下是质量控制报告的链接:http://qc.embarcadero.com/wc/qcmain.aspx?d=112101
答案 0 :(得分:27)
首先,这与泛型无关,但在使用泛型时更有可能表现出来。事实证明TControl.CreateParams
中存在缓冲区溢出错误。如果您查看代码,您会注意到它填充了TCreateParams
结构,尤其重要的是,它使用当前类的名称(TCreateParams.WinClassName
)填充ClassName
。不幸的是WinClassName
是一个只有64
个字符的固定长度缓冲区,但是需要包含NULL终止符;如此有效的64
char 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个或更少。泛型类型的情况并非如此:我遇到了一个带有2个类型参数的TWinControl后代遇到这个问题,所以它的形式是:
TMyControlName<Type1, Type2>
基于此泛型类型的具体类型的gnerate ClassName采用以下形式:
TMyControlName<UnitName1.Type1,UnitName2.Type2>
所以它包括5个标识符(2x单位标识符+ 3x类型标识符)+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的HASH以帮助解决唯一性问题:
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;