XE2中的COM是否中断，我如何解决它？ [英] Is COM broken in XE2, and how might I work around it?
问题描述
更新： XE2 Update 2修复了以下错误。
下面的程序从实际程序中截断，在XE2。这是一个2010年的回归。我没有XE测试，但我希望该程序在XE上运行良好（感谢Primož确认代码在XE上运行良好）。
程序COMbug;
{$ APPTYPE CONSOLE}
使用
SysUtils，Variants，Windows，Excel2000;
var
Excel：TExcelApplication;
Book：ExcelWorkbook;
工作表：ExcelWorksheet;
UsedRange：ExcelRange;
Row，Col：Integer;
v：Variant;
begin
Excel：= TExcelApplication.Create（nil）;
try
Excel.Visible [LOCALE_USER_DEFAULT]：= True;
Book：= Excel.Workbooks.Add（EmptyParam，LOCALE_USER_DEFAULT）as ExcelWorkbook;
Sheet：= Book.Worksheets.Add（EmptyParam，EmptyParam，1，EmptyParam，LOCALE_USER_DEFAULT）as ExcelWorksheet;
Sheet.Cells.Item [1,1] .Value：= 1.0;
Sheet.Cells.Item [2,2] .Value：= 1.0;
UsedRange：= Sheet.UsedRange [LOCALE_USER_DEFAULT] as ExcelRange;
for Row：= 1 to UsedRange.Rows.Count do begin
for Col：= 1 to UsedRange.Columns.Count do begin
v：= UsedRange.Item [Row，Col] .Value ;
end;
end;
finally
Excel.Free;
end;
end。
在XE2 32位中的错误是：
< blockquote>
Project COMbug.exe引发异常类$ C000001D，并在0x00dd6f3e处显示系统异常（代码0xc000001d）。
第二次执行 UsedRange.Columns 时出现错误。
在XE2 64位错误is：
项目COMbug.exe引发异常类$ C0000005，并显示消息'c0000005 ACCESS_VIOLATION'
再次，我认为错误发生在第二次执行 UsedRange.Columns ，但64位调试程序通过
我已经提交了一个问题报告。
我看起来很像我在Delphi COM中的东西/ automation / interface stack被全面打破。这是我XE2采用的一个完整的显示。
有没有人有这个问题的任何经验？有没有人有任何提示和建议，如何我可以尝试解决这个问题？
解决方法
rowCnt：= UsedRange.Rows.Count;
colCnt：= UsedRange.Columns.Count;
for Row：= 1 to rowCnt do begin
for Col：= 1 to colCnt do begin
v：= UsedRange.Item [Row，Col] .Value;
end;
end;
这也有效（并且可以帮助您在更复杂的用例中找到解决方法）：
function ColCount（const range：ExcelRange）：integer;
begin
结果：= range.Columns.Count;
end;
for Row：= 1 to UsedRange.Rows.Count do begin
for Col：= 1 to ColCount（UsedRange）do begin
v：= UsedRange.Item [Row，Col ]。值;
end;
end;
分析
在执行_Release时在DispCallByID中的Win.ComObj
varDispatch，varUnknown：
begin
if PPointer ）^<> nil then
IDispatch（Result）._ Release;
PPointer（Result）^：= Res.VDispatch;
end;虽然在Delphi XE（XE使用汇编语言版本）中的相同过程的PUREPASCAL版本是不同的。 .. varDispatch，varUnknown：
begin
if PPointer（Result）^& nil then
IDispatch（Result.VDispatch）._ Release;
PPointer（Result）^：= Res.VDispatch;
end;
...在这两种情况下，汇编代码是相同的（EDIT：not true，结束时）：
@ResDispatch：
@ResUnknown：
MOV EAX，[EBX]
TEST EAX，EAX
JE @@ 2
PUSH EAX
MOV EAX，[EAX]
CALL [EAX] .Pointer [8]
@@ 2：MOV EAX，[ESP + 8]
MOV [EBX]，EAX
JMP @ResDone
b $ b
有趣的是，这会崩溃...
for Row：= 1 to UsedRange.Rows.Count do begin
for Col：= 1 to UsedRange.Columns.Count do begin
end;
end;
...而这不是。
row：= UsedRange.Rows.Count;
col：= UsedRange.Columns.Count;
col：= UsedRange.Columns.Count;
这样做的原因是使用隐藏的局部变量。在第一个示例中，代码编译为...
00564511 6874465600 push $ 00564674
00564516 6884465600 push $ 00564684
0056451B A12CF35600 mov eax，[$ 0056f32c]
00564520 50 push eax
00564521 8D8508FFFFFF lea eax，[ebp- $ 000000f8]
00564527 50 push eax
00564528 E8933EEAFF调用DispCallByIDProc
...并且调用两次。
在第二个示例中，使用堆栈上的两个不同的临时位置（ebp - ???? offsets）：
00564466 6874465600 push $ 00564674
0056446B 6884465600 push $ 00564684
00564470 A12CF35600 mov eax，[$ 0056f32c]
00564475 50 push eax
00564476 8D8514FFFFFF lea eax，[ebp- $ 000000ec]
0056447C 50 push eax
0056447D E83E3FEAFF call DispCallByIDProc
...
0056449B 6874465600 push $ 00564674
005644A0 6884465600 push $ 00564684
005644A5 A12CF35600 mov eax，[$ 0056f32c ]
005644AA 50 push eax
005644AB 8D8510FFFFFF lea eax，[ebp- $ 000000f0]
005644B1 50 push eax
005644B2 E8093FEAFF call DispCallByIDProc
当存储在此临时位置的内部接口被清除时，会发生错误，只有当第二次执行for因为有一些已经存储在这个接口 - 它是放在那里，当第一次被调用时。在第二个例子中，使用了两个位置，所以这个内部接口总是初始化为0，并且根本不调用Release。
真正的bug是内部接口包含垃圾，当调用Release时，会发生。
经过一些挖掘，我注意到汇编代码释放了旧接口不一样 - XE2版本缺少一个mov eax，[eax]指令。 IOW，
IDispatch（Result）._ Release;
是一个错误，它真的应该是
IDispatch（Result.VDispatch）._ Release;
讨厌的RTL错误。
Update: XE2 Update 2 fixes the bug described below.
The program below, cutdown from the real program, fails with an exception in XE2. This is a regression from 2010. I don't have XE to test on but I'd expect that the program works fine on XE (thanks to Primož for confirming that the code runs fine on XE).
program COMbug;
{$APPTYPE CONSOLE}
uses
SysUtils, Variants, Windows, Excel2000;
var
Excel: TExcelApplication;
Book: ExcelWorkbook;
Sheet: ExcelWorksheet;
UsedRange: ExcelRange;
Row, Col: Integer;
v: Variant;
begin
Excel := TExcelApplication.Create(nil);
try
Excel.Visible[LOCALE_USER_DEFAULT] := True;
Book := Excel.Workbooks.Add(EmptyParam, LOCALE_USER_DEFAULT) as ExcelWorkbook;
Sheet := Book.Worksheets.Add(EmptyParam, EmptyParam, 1, EmptyParam, LOCALE_USER_DEFAULT) as ExcelWorksheet;
Sheet.Cells.Item[1,1].Value := 1.0;
Sheet.Cells.Item[2,2].Value := 1.0;
UsedRange := Sheet.UsedRange[LOCALE_USER_DEFAULT] as ExcelRange;
for Row := 1 to UsedRange.Rows.Count do begin
for Col := 1 to UsedRange.Columns.Count do begin
v := UsedRange.Item[Row, Col].Value;
end;
end;
finally
Excel.Free;
end;
end.
In XE2 32 bit the error is:
Project COMbug.exe raised exception class $C000001D with message 'system exception (code 0xc000001d) at 0x00dd6f3e'.
The error occurs on the second execution of UsedRange.Columns.
In XE2 64 bit the error is:
Project COMbug.exe raised exception class $C0000005 with message 'c0000005 ACCESS_VIOLATION'
Again, I think that the error occurs on the second execution of UsedRange.Columns, but the 64 bit debugger steps through the code in a slightly weird way so I'm not 100% sure of that.
I have submitted a QC report for the issue.
I looks very much to me as though something in the Delphi COM/automation/interface stack is comprehensively broken. This is a complete show-stopper for my XE2 adoption.
Does anyone have any experience of this problem? Does anyone have any tips and advice as to how I might attempt to work around the problem? Debugging what's really going on here is outside my area of expertise.
解决方案 Workaround
rowCnt := UsedRange.Rows.Count;
colCnt := UsedRange.Columns.Count;
for Row := 1 to rowCnt do begin
for Col := 1 to colCnt do begin
v := UsedRange.Item[Row, Col].Value;
end;
end;
This also works (and may help you find a workaround in more complicated use cases):
function ColCount(const range: ExcelRange): integer;
begin
Result := range.Columns.Count;
end;
for Row := 1 to UsedRange.Rows.Count do begin
for Col := 1 to ColCount(UsedRange) do begin
v := UsedRange.Item[Row, Col].Value;
end;
end;
Analysis
It crashes in System.Win.ComObj in DispCallByID when executing _Release in
varDispatch, varUnknown:
begin
if PPointer(Result)^ <> nil then
IDispatch(Result)._Release;
PPointer(Result)^ := Res.VDispatch;
end;
Although the PUREPASCAL version of this same procedure in Delphi XE (XE uses an assembler version) is different ...
varDispatch, varUnknown:
begin
if PPointer(Result)^ <> nil then
IDispatch(Result.VDispatch)._Release;
PPointer(Result)^ := Res.VDispatch;
end;
... the assembler code in both cases is the same (EDIT: not true, see my notes at the end):
@ResDispatch:
@ResUnknown:
MOV EAX,[EBX]
TEST EAX,EAX
JE @@2
PUSH EAX
MOV EAX,[EAX]
CALL [EAX].Pointer[8]
@@2: MOV EAX,[ESP+8]
MOV [EBX],EAX
JMP @ResDone
Interestingly enough, this crashes ...
for Row := 1 to UsedRange.Rows.Count do begin
for Col := 1 to UsedRange.Columns.Count do begin
end;
end;
... and this doesn't.
row := UsedRange.Rows.Count;
col := UsedRange.Columns.Count;
col := UsedRange.Columns.Count;
The reason for this is the use of hidden local variables. In the first example, the code compiles to ...
00564511 6874465600 push $00564674
00564516 6884465600 push $00564684
0056451B A12CF35600 mov eax,[$0056f32c]
00564520 50 push eax
00564521 8D8508FFFFFF lea eax,[ebp-$000000f8]
00564527 50 push eax
00564528 E8933EEAFF call DispCallByIDProc
... and that is called twice.
In the second example, two different temporary locations on the stack are used (ebp - ???? offsets):
00564466 6874465600 push $00564674
0056446B 6884465600 push $00564684
00564470 A12CF35600 mov eax,[$0056f32c]
00564475 50 push eax
00564476 8D8514FFFFFF lea eax,[ebp-$000000ec]
0056447C 50 push eax
0056447D E83E3FEAFF call DispCallByIDProc
...
0056449B 6874465600 push $00564674
005644A0 6884465600 push $00564684
005644A5 A12CF35600 mov eax,[$0056f32c]
005644AA 50 push eax
005644AB 8D8510FFFFFF lea eax,[ebp-$000000f0]
005644B1 50 push eax
005644B2 E8093FEAFF call DispCallByIDProc
The bug occurs when an internal interface stored in this temporary location is being cleared, which happens only when the "for" case is executed for the second time because there's something already stored in this interface - it was put there when "for" was called for the first time. In the second example, two locations are used so this internal interface is always initialized to 0 and Release is not called at all.
The true bug is that this internal interface contains garbage and when Release is called, sh!t happens.
After some more digging, I noticed that the assembler code that frees the old interface is not the same - XE2 version is missing one "mov eax, [eax]" instruction. IOW,
IDispatch(Result)._Release;
is a mistake and it really should be
IDispatch(Result.VDispatch)._Release;
Nasty RTL bug.
这篇关于XE2中的COM是否中断，我如何解决它？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
